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Keywords: 

o  Data  Base  Management  Systems 

o  Military  Intelligence  Analysis 

o  Indications  and  Warnings 

o  Computer  Simulation 

o  Remote  Terminal  Emulation 


S'  •*»«.' 

j  .  *  :  tl  fi-r  i  i  r,r- 


TABLE  OF  CONTENTS 


1.0  INTRODUCTION  AND  SUMMARY  . 

1.1  Purpose  of  the  Final  Technical  Report  . 

1.2  Summary  of  Results  . 

1.3  Project  References  . 

1.4  Terms  and  Abbreviations . .  .  . 

2.0  DATA  BASE  MANAGEMENT  SYSTEM  SELECTION  . 

3.0  SCENARIO  DEVELOPMENT  . 

4.0  TASK  INFORMATION  BLOCKS  (TIBs)  . 

5.0  DATA  BASE  GENERATION  . 

6.0  WEIS/EWAMS  DATA  BASE  . 

7.0  LIBYAN  SCENARIO  DEVELOPMENT  . 

8.0  SCHEMA  DEFINITIONS  . 

9.0  GENERAL  PURPOSE  MONITOR  . 

10.0  GENERAL  DESCRIPTION  OF  SYSTEMS  TESTED  . 

10.1  ADABAS-M  Characteristics  .  . 

10.2  ORACLE  Characteristics  . 

10.3  SEED  Characteristics . .  . 

11.0  USE  OF  SYSTEM  . 

12.0  BENCHMARK  TEST  METHODOLOGY  . 

13.0  BENCHMARK  TEST  RESULTS  AND  ANALYSIS  .  . 

13.1  Benchmark  Execution  and  Results  .  .  .  . 

13.2  Comparative  Analysis  by  Type  of  Activity 


TABLE  OF  CONTENTS  (continued) 


14.0  QUALITATIVE  EVALUATION  FACTORS 

14.1  Qualitative  Evaluations  .  .  . 


14.2  Analyst-User  Viewpoint 

14. 3  Programmer  Viewpoint  . 


15.0  CONCLUSIONS  AND  RECOMMENDATIONS 


15.1  Conclusions 


15.2  Recommendations 


Appendix  A 
Appendix  B 


ENGLISH  LANGUAGE  SCENARIOS 


Generalized  I&W  Scenario 


Watch  Function 


Military  Systems  Analysis 
Collection  Coordination  . 


MAC  Route  Assessment 


I&W  Analysis 


Area  Analysis  . 

Space  Event  Assessment  (not  implemented)  .  , 
Missile  Threat  Assessment  (not  implemented) 

ELINT  Analysis  (not  implemented)  . 

Updates  . 


Appendix  C  SCENARIOS  IN  DHIL 


Appendix  D  TASK  INFORMATION  BLOCKS  (TIBS) 


Appendix  E 
Appendix  F 


GENERAL  PURPOSE  MONITOR 


FURTHER  RESEARCH 


Artificial  Intelligence  Experiments 


Data  Base  Machine  Experiments 


Knowledge  Based  Processor 


14-10 

14-14 


LIST  OF  APPENDICES 


DATABASE  HIGHORDER  INTERACTIVE  LANGUAGE  (DHIL)  .  .  . 


Page 


LIST  OF  FIGURES 


Page 


4-1  Form  Used  for  Specification  of  Task  Information  Block  Values  .  H-2a 

C— 1  WATCH  Function .  C-la 

C-2  I&W  Analyst .  C-13a 

C-3  Collection  Coordination  .  C-27a 

C-4  Area  Analysis .  c-38a 

C-5  Military  -  Systems  -  Analysis .  c-49a 

C-6  MAC  Route  Assessment .  C-64a 


LIST  OF  TABLES 

Page 


2-1  Candidate  DBMSs .  2-1  a 

6-1  Alphabetical  Listing  of  WEIS  Actors .  6-2a 

6-2  Listings  of  WEIS  Event  Interaction  Codes  .  6 -2c 

6-3  Listings  of  Conflict  Arena  Codes  .  6-2f 

13-1  Files  Used  by  Watch  Functions  Scenarios  .  13-3a 

13-2  Implementation  Status  of  Scenarios  of  ADABAS-M  .  13-5a 

13-3  TIB  Schema  Complexity  Level  .  13-6 a 

13-4  TIBs  Per  Scenario . . .  13 -6b 

13-5  Scenarios  for  ORACLE .  13-8a 

13-6  Test  Series  Summary  Descriptions .  1 3— 8b 

13-7  Relative  Comparisons  .  13-8u 

13-8  I&W  DBMS  Analysis  Test  Summary .  13-8aa 

13-9  UPDATE  Performance  (ADABAS-M  and  ORACLE)  .  13-l6a 

13-10  Correlations  of  Resource  Utilization  to  Workload  .  13—1 8a 

A-1  Translation  of  DHIL  Statements .  A-13a 

D-1  Examples  of  Task  Information  Block  (TIB)  .  D-la 


This  Final  Technical  Report  for  the  Indications  and  Warning  Data  Base 
Management  System  Analysis  (Contract  No.  F30602-80-C-0286)  is  written  to 
provide: 

a.  A  summary  of  tasks  undertaken  and  completed  during  the  course  of 
the  project. 

b.  Results  of  experiments  and  tests  performed. 

c.  Recommendations  resulting  from  experiments,  tests,  and  other 
evaluation  procedures. 

The  objective  of  the  project  was  to  conduct  research  involving  Data  Base 
Management  System  (DBMS)  characteristics  for  Indications  and  Warning 
(I&W) .  The  I&W  analysts  within  the  USAF  currently  do  not  have  a 
comprehensive  data  base  of  relevant  information.  Data  are  stored  randomly 
in  various  forms  and  formats.  No  DBMS  aids  are  employed  to  assist  in 
storage,  retrieval,  and  analysis.  The  thrust  of  this  project  has  been  a 
first  effort  to  develop  I&W  DBMS  characteristics. 

The  analysis  was  performed  by  Measurement  Concept  Corporation  (Me2) ,  with 
the  assistance  of  Betac  Corporation  under  subcontract.  Five  major  tasks 
were  performed: 

o  A  review  of  various  types  of  intelligence  analysis  at  SAC, 

ADCOM,  and  DIA  to  develop  the  characteristics  of  the  functions 
and  present  operations.  In  addition,  an  I&W  data  base  to  support 
the  analyst  was  designed  and  a  simulation  of  the  data  base 
was  developed. 


o 


A  study  of  available  state-of-the-art  DBMS  technology  which 
could  be  recommended  as  a  testbed  DBMS.  Three  DBMS  packages  were 
selected  for  benchmark  testing. 


o  Development  of  testbed  software. 

o  Benchmark  testing  of  the  selected  DBMSs  against  such  evaluation 
factors  as  data  base  creation,  update,  storage  and  retrieval. 

o  A  recommendation  of  a  DBMS  with  associated  hardware  to  solve  the 
I&W  problem. 

1 .?  Summary  of  Results 

Three  Data  Base  Management  Systems  (DBMSs)  were  selected  for  extensive 
testing: 

o  ADABAS-M,  an  indexed  system 

o  ORACLE,  a  relational  system 

o  SEED,  a  network  system  using  CODASYL  conventions 

Of  the  three  DBMSs  tested  during  this  project,  ADABAS-M  is  the  undisputed, 
in  fact,  unchallenged  winner  by  measures  of  efficiency.  It  loaded  faster, 
retrieved  faster  (with  the  exception  of  a  single  test),  and  it  updated 
faster.  Furthermore,  the  areas  recommended  for  improvement  appear  to  be 
areas  in  which  improvements  could  be  accomplished  with  relative  ease. 

Although  ORACLE  did  not  compare  favorably  to  ADABAS-M  in  performance 
measures,  it  is  by  nature  at  somewhat  of  a  disadvantage.  ORACLE  provides 
more  functional  power  in  its  non-procedural  language  and  it  supports  a 
more  general  and  basic  data  model  than  does  ADABAS-M.  In  computer 
systems,  enhanced  functional  power  is  almost  always  achieved  at  the 
expense  of  additional  resource  utilization. 


SEED  could  not  be  tested  as  thoroughly  as  desired.  To  do  so,  would  have 
consumed  a  disproportionate  amount  of  project  labor  resources.  The  effort 
required  to  develop  a  responsive  data  base  under  the  CODASYL  model  of  data 
supported  by  SEED  is  truly  enormous.  The  model  is  potentially  conducive 
to  efficient  processing  in  restricted,  stable,  well  defined  enterprises. 
In  such  cases  it  would  be  worth  the  large  design  effort.  Results  during 
this  project  showed  that;  without  custom  designed  input,  SEED  is 
prohibitively  slow  in  the  initial  data  base  load.  A  data  base  design 
created  with  one  type  of  query  in  mind  will  not  likely  support  other  t  j 
of  queries.  The  flexibility  and  expandability  of  CODASYL  data  bast  vs 
severely  limited. 

Whatever  their  relative  merits  may  be,  examination  of  the  results  of  thc3e 
tests  shows  that  none  of  the  three  DBMSs  have  performance  characteristics 
required  to  support  I&W  systems  of  the  near  future.  Even  the  most 
efficient  of  the  three,  ADABAS-M,  cannot  be  expected  to  support  more  than 
approximately  25  typical  I&W  analyst  requests  per  minute.  The  addition  of 
data  intensive  inference  and  decision  aid  applications,  supporting 

numerous  analysts,  will  require  greater  data  throughput  than  can  be 
supplied  by  any  of  the  three  DBMSs  in  question. 

ADABAS-M  would  support  typical  I&W  centers  of  today.  ORACLE,  because  of 
its  much  greater  logical  power  and  ease  of  use,  might  be  preferred  for 
smaller  I&W  centers  (up  to  5  analysts),  but  it  cannot  adequately  support 
the  larger  ones. 

The  I&W  centers  of  the  near  future  will  support  more  analysts,  will 
support  more  comprehensive  data  bases,  and  will  include  sophisticated, 
data  intensive,  inference  logic  applications  and  decision  aids.  To 

achieve  these  goals,  conventional  computer  systems  will  not  suffice.  What 
will  be  needed  is  special  purpose  machinery  devoted  to  the  data  base  task 
and  serving  the  host  as  a  peripheral.  This  machinery  must  employ  parallel 
processing  (eventually  large  scale),  and  some  form  of  muJtipie  channel 
data  streaming  (to  avoid  mechanical  penalties)  or  multi-billion  byte 
non-mechanical  memories,  preferably  also  with  multiple  channel  access. 
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Such  a  device  is  currently  called  a  "data  base  machine".  Other  devices 
which  achieve  some,  but  not  all,  of  the  characteristics  of  a  data  base 
ma'chine  are  so  termed.  Some  are  currently  commercially  available,  and 
some  are  in  development.  The  IDM-500  is  a  good  example  of  currently 
available  data  base  machine  technology.  In  full  configuration,  it  i3 
advertised  as  increasing  data  access  speeds  by  a  factor  of  5  to  10.  It 
should  be  benchmarked  against  the  same  scenarios  performed  during  this 
project  to  assess  its  capability  to  support  I&W  analysis  requirements  for 
the  near  term  ('v  5  years).  The  IDM  may  be  viewed  as  a  relatively  easily 
implemented,  cost  effective  stop-gap  measure  to  hold  the  line  until  true 
"multiple  instruction,  multiple  data  (MIMD)"  machines  are  realized.  An 
RADC  sponsored  MIMD  machine,  the  Gaertner  G-471,  should  be  benchmarked 
against  the  scenarios  used  in  this  project  to  determine  its  capability  to 
provide  data  base  support  in  the  mid-to-long  term  (5-10  years). 

Several  caveats  are  noted  in  the  body  of  this  report,  of  which  the 
following  are  most  signficant: 

o  In  accordance  with  the  terms  of  the  contract,  a  DEC  PDP-11/70 
minicomputer  under  the  IAS  operating  system,  with  two  HP06  disk  drives, 
was  used  for  all  experimentation.  A  more  powerful  central  processor,  a 
different  operating  system,  and  additional  storage  capacity  would  greatly 
improve  performance  characteristics  for  all  systems  tested. 

o  Problems  with  the  implementation  of  ADABAS-M  have  led  the  vendor 
to  withdraw  the  system  from  further  sale.  When  and  if  this  product  is 
substantially  modified  and  returned  to  the  market,  it  should  be 
reconsidered  for  possible  recommendation. 

o  Errors  and  limitations  in  the  SEED  implementation  may  reflect 
the  need  to  modify  this  system  for  operation  under  IAS.  Performance  under 
another  operating  system  could  be  considerably  more  reliable. 
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o  The  version  of  ORACLE  used  for  testing  was  2.3.  During  the 

course  of  the  project,  a  new  version,  ORACLE  3.0,  was  introduced  but  not 
tested.  If  the  vendor's  claims  for  improved  performance  are  borne  out  in 
practice,  the  recommendation  of  ORACLE  as  the  basis  for  an  I&W  analysis 
system  would  be  strengthened. 

o  In  accordance  with  the  emphasis  in  the  SOW  on  the  relational 
data  model,  some  bias  toward  this  model  existed  throughout  the  design  of 
the  data  base.  If  this  emphasis  were  not  justified,  there  may  have  been  an 
unfair  bias  against  SEED,  which  used  a  distinctively  different  data  model. 

o  In  particular,  for  applications  in  which  the  structure  of  the 
data  base  does  not  change  frequently,  and  where  the  emphasis  is  placed  on 
simple,  routine  queries,  the  greater  efficiency  of  SEED  could  make  it  the 
system  of  choice. 

Development  of  a  testbed  system  for  evaluation  of  selected  DBMSs  has 
provided  RADC  with  an  extensive  hardware/software  configuration  for 
further  testing  and  evaluation  of  tools  and  materials  for  the  support  of 
intelligence  analysis.  Among  the  products  developed  and  delivered  to  RADC 
are  the  following: 

o  Scenarios  representing  detailed  activities  of  intelligence 

analysts  in  their  use  of  a  projected  DBMS. 

o  Comprehensive  specifications  of  an  I&W  data  base  to  support  the 
scenarios. 

o  A  simulated  I&W  data  base  for  use  in  tests  and  evaluation. 

o  Detailed  specifications  for  the  Database  Highorder  Interactive 

Language  (DHIL)  for  representing  I&W  scenarios. 

o  Support  programs  to  assist  in  translating  from  DHIL  into 

applications  programs  for  the  DBMSs. 
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o  Control  programs  for  scheduling  *nd  monitoring  performance  of 
the  scenarios. 

o  A  complete  Libyan  Crisis  scenario  for  research  into  analyst 
performance. 

o  Software  to  generate  maps  and  other  displays  for  use  in 
demonstrations  of  system  operation. 

1.3  Project  References 
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May  1982. 

o  I&W  DBMS  Analysis:  Live  Test  Demonstration,  10  May  1982. 
o  I&W  DBMS  Analysis:  Benchmark  Test  Results,  December  1982. 

1.4  Terms  and  Abbreviations 

The  following  are  terms,  definitions,  and  acronyms  used  in  this  document 
and  subject  to  interpretation  by  the  user. 

AI  -  Artificial  Intelligence 

AOV  -  Analysis  of  Variance 

BMD  -  Benchmark  Driver 

DBA  -  Data  Base  Administrator 

DBG  -  Data  Base  Generator 

DBMS  -  Data  Base  Management  System 

EMT  -  Emulated  Trap 

EWAMS-  Early  Warning  and  Monitoring  System 

GPM  -  General  Purpose  Monitor 

HLI  -  Host  Language  Interface 

I&W  -  Indications  and  Warnings 

LTD  -  Live  Test  and  Demonstration 

RTE  -  Remote  Terminal  Emulation 

SPM  -  Special  Purpose  Monitor 

SUT  -  System  Under  Test 

TIB  -  Task  Information  Block 

WEIS  -  World  Events/Interaction  Series 
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This  section  provides  a  brief  summary  of  the  procedures  used  in  selecting 
three  Data  Base  Management  Systems  (DBMSs)  for  benchmark  testing. 
Information  is  drawn  from  the  project  report  "DBMS  Selection  Study,"  June 
1981. 

Two  tasks  supported  this  selection  study: 

o  A  functional  analysis  identifying  IAW  users  and  information 
products,  which  formed  the  basis  for  the  scenarios  presented  in  Section 
3.0  of  this  report.  Each  of  the  scenarios  was  documented  in  flowchart  form 
and  was  also  described  in  the  DHIL. 

o  A  general  survey  of  DBMSs  suitable  for  implementation  on  DEC 
PDP-11/70  hardware  under  the  IAS  operating  system.  Eight  candidate  systems 
were  identified,  and  vendor-supplied  documentation,  such  as  system 
descriptions  and  reference  manuals,  reports  of  previous  performance  and 
benchmark  tests,  and  technical  literature  were  reviewed.  Nearly  180  DBMS 
features  were  considered  in  the  survey. 

Eight  candidate  systems  were  chosen.  Their  types  and  vendors  are  listed  in 
Table  2-1. 

The  selection  procedure  involved  three  major  steps: 

o  Define  desired  DBMS  functions  and  their  relative  importance  to 
I&V  data  base  management  needs. 

o  Rate  each  DBMS  against  the  desired  functions  on  a  0-10  scale, 
with  10  scoring  highest. 

o  Total  the  scores  based  on  the  relative  importance  of  the 
function. 


DBMS 


Vendor 


lyes 


ADABAS-M 

Software  AG 

ORACLE 

Relational  Software 

SARP-V 

Bunker  Ramo 

MADMAN 

General  Electric 

DBMS- 11 

DEC 

TOTAL 

Cincom  Systems 

SEED 

International  Data 

Base  Systems 

REL*STOR 

GTE 

Indexed 

Relational 

Indexed 

Network/CODASYL 

Network/CODASYL 

Network 

Network/CODASYL 

Relational 


Table  2-1  Candidate  DBMSs 


On  the  basis  of  this  formal  selection  process,  the  following  DBMSs  were 
designated  for  testing  and  evaluation: 

o  ADABAS-M,  an  indexed  DBMS,  developed  for  DEC  minicomputer 

applications.  It  should  be  noted  that  ADABAS-M  is  a  completely 
new  product,  not  an  adaptation  of  the  older  ADABAS  system  for 
IBM  equipment. 

o  ORACLE,  a  relatively  new  relational  DBMS. 

o  SEED,  a  network-type  DBMS  based  on  CODASYL  conventions. 

In  addition  to  these  three  systems,  three  others  were  identified  as 
candidates  for  further  study: 

o  SARP-V 

o  REL*STOR 

o  A  data  base  machine 

SARP-V  is  currently  widely  used  as  an  intelligence  DBMS,  and  might  be  used 
as  a  baseline  system.  REL#STOR  might  have  been  of  interest  as  an 
alternative  to  ORACLE  when  a  relational  system  is  under  consideration. 
However,  REL*STOR  has  since  been  removed  from  the  market.  A  data  base 
machine  might  be  considered  as  the  cost  of  hardware  continues  to  decline, 
making  a  specialized  machine  cost-competitive  with  a  software  DBMS  running 
on  a  general-purpose  processor. 

The  three  systems  selected  for  comparative  evaluation,  then,  were 
ADABAS-M,  ORACLE,  and  SEED,  representing  indexed,  relational,  and  network 
approaches,  respectively. 
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This  section  briefly  describes  the  Database  Highorder  Interactive  Language 
(DHIL),  developed  by  Betac  Corporation  and  revised  by  Me2,  for  the 
precise,  detailed  representation  of  I&W  analyst  scenarios.  It  also 
describes  the  methods  by  which  the  scenarios  were  developed.  A  detailed 
description  of  the  DHIL  is  provided  in  Appendix  A  of  this  report.  English 
language  versions  of  the  scenarios  are  contained  in  Appendix  B.  A  full 
presentation  of  the  scenarios,  written  in  DHIL,  is  contained  in  Appendix 
C. 

The  DHIL  is  a  specialized  language  for  scenario  representation.  It 
incorporates  calls  to  the  DBMS,  control  structures,  and  provisions  for 
"think  times,"  or  designated  pauses  in  scenario  execution.  Use  of  the  DHIL 
permits  a  precise,  unambiguous  specification  of  scenario  elements, 
including  control  elements  (such  as  loops  or  repeated  actions,  conditional 
actions,  and  randomly  determined  actions).  The  DHIL  specifications  can 
then  be  translated  into  the  specific  formats  required  by  the  DBMSs  under 
test.  In  general,  these  were  FORTRAN  programs  calling  on  specialized 
subroutines  supplied  by  the  vendors.  Use  of  the  DHIL  for  specification  of 
the  scenarios  helped  to  ensure  that  all  DBMSs  would  be  tested  against  the 
same  benchmark. 

A  "scenario"  contains  a  list  of  commands  that  the  simulated  user  sends  to 
the  system  under  test.  The  scenarios  provide  for  "think  times,"  which 
represent  periods  during  which  the  user  is  not  interacting  with  the 
system.  The  DHIL  specifications  also  make  it  possible  to  define  control 
structures,  such  as  repeated  actions  or  a  return  to  a  previous  action. 

To  simulate  the  use  of  the  system  by  several  analysts,  replications  of 
some  of  the  scenarios  were  used.  The  use  of  multiple  copies  of  the  same 
scenario  would  have  created  an  unrealistic  simulation  if  all  of  the 
scenarios  were  accessing  the  same  records  at  the  same  time.  To  prevent 
this  situation,  and  to  add  to  the  realism  of  the  simulation  of  multiple 
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terminals,  the  system  random  number  generator  is  used  to  provide  a 
sequence  of  pseudo-random  numbers  as  the  basis  for  the  selection  of 
records  to  be  accessed.  The  sequence  of  pseudo-random  numbers  is  a 
function  of  the  "seed,"  or  starting  value  for  the  random  number  generator. 
Through  the  use  of  identical  seeds,  identical  simulations  could  be 
generated  for  each  of  the  DBMSs  under  test. 

The  scenarios  provide  an  operational  definition  of  the  user's 
requirements.  If  a  DBMS  can  execute  a  scenario,  then  it  meets  the  minimum 
requirements  of  the  users.  The  better  it  does  on  the  scenario  (in  terms  of 
time,  resource  requirements,  costs,  and  other  evaluation  factors),  the 
better  it  is  for  the  intended  application. 

Scenarios  were  created  by  Betac  Corporation,  based  on  interviews  with  and 
observation  of  I&W  analysts  at  ADCOM,  MAC,  SAC,  and  the  NMIC.  Analyst 
actions  contained  in  the  scenarios  are  felt  to  be  typical  of  I&W  analysts 
in  normal  and  crisis  operations.  An  additional  scenario  provides  repeated 
updates  of  the  data  base,  to  test  DBMS  update  capabilities. 

The  following  six  scenarios  were  developed: 

o  Watch 

o  IAW  Analysis 

o  Collection  Coordination 

o  Area  Analysis 

o  Military  System  Analysis 

o  MAC  Route  Assessment 
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Three  additional  scenarios  were  designed  by  Betac  but  not  fully  developed: 

o  Space  Event  Assessment 

o  Missile  Threat  Assessment 

o  ELINT  Analysis 

Scenarios  were  varied  in  the  following  ways: 

o  Pseudo-random  numbers  were  used  to  simulate  variations  in 
performance  of  the  analyst  tasks.  Since  the  pseudo-random  numbers  are 
functions  of  the  "seed"  (a  number  which  is  used  to  initiate  a  sequence  of 
pseudo-random  numbers),  the  same  set  of  actions  could  be  performed  for 
each  of  the  systems  under  test,  simply  by  using  the  same  seed  for  each 
test. 

o  Varied  levels  of  alert  (peace,  crisis,  war)  may  be  simulated. 
These  affect  the  rate  at  which  actions  are  performed,  primarily  by  varying 
the  "think  times." 

o  Varied  loads  were  introduced,  including  variations  in  the  number 
of  terminals  and  in  the  number  of  scripts  to  be  processed  at  each 
terminal. 

Following  receipt  of  the  scenarios  from  Betac,  Me2  personnel  reviewed  and 
revised  them  to  remove  inconsistencies  and  to  eliminate  incompatibilities 
with  the  data  base  designs.  Me2  also  prepared  an  "update  scenario," 
consisting  of  repeated  updates  to  the  data  base,  to  test  the  efficiency 
and  reliability  of  this  operation.  The  scenarios  were  then  reviewed  by 
RADC/IN,  which  reported  that  they  accurately  represented  analyst 
activities. 
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The  scenarios  were  next  translated  into  "scripts, n  which  are  computer 
programs  written  in  a  language  (such  as  FORTRAN)  which  is  acceptable  to  a 
specific  system  under  test.  The  scripts  were  executed  under  the  control  of 
the  Benchmark  Driver.  Once  an  individual  script  began  execution,  it 
functioned  as  a  separate  task,  issuing  calls  to  the  DBMS  at  specified 
intervals.  "Think  times,"  during  which  the  emulated  analyst  was  reading 
messages  and  performing  other  tasks,  were  represented  by  wait  times  within 
the  scripts. 

Execution  of  the  scripts  was  monitored  by  the  General  Purpose  Monitor 
(GPM),  which  is  described  in  Section  8.0.  The  GPM  records  data  concerning 
resource  utilization  and  other  performance  factors. 

The  scenarios  are  a  major  resource  for  testing  and  evaluating  DBMSs.  They 
represent  analyst  activities  at  a  level  of  detail  which  has  not  been 
otherwise  obtainable.  With  their  accompanying  data  base,  they  will  be 
valuable  for  testing  and  demonstrating  other  DBMSs  and  components  of  an 
I&W  analyst  facility,  within  the  context  of  an  Intelligence  Systems 
Laboratory. 
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Task  Information  Blocks  (TIBs)  are  specifications  of  individual  files  to 
be  created  to  support  the  scenarios.  The  TIBs  were  designed  by  Betac,  and 
were  reviewed  and  modified  by  Mc^  to  eliminate  inconsistencies  with  the 
scenarios. 

The  TIBs  used  for  the  simulations  are  described  in  Appendix  D  of  this 
report.  Since  the  TIBs  specify  the  contents  of  an  I&W  data  base  of 
sufficient  size  and  complexity  to  support  the  scenarios,  they  represent 
one  of  the  contributions  of  this  project  to  future  development  of  an  I&W 
data  management  system. 

The  following  TIBs  were  specified: 

A001 .  Message  Processing  Input/Output  (based  on  GENSER  message 
traffic) 

B001 .  Event  Records 

C001 .  Order  of  Battle 

D001 .  Weapons/Equipment  Summary 

D002.  Personalities 

E001 .  Country  Summary  Information 

E002.  Installation  Data 

F001.  Indicator  Lists 

G001.  Collection  Requests 
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HO 01.  Friendly  Mission  Information 

1001 .  Air  Route  Mission  Data 

1002.  Air  Route  Segment  Data 

J001 .  Weather  Data 

A  Data  Base  Generator  (DBG)  was  used  in  conjunction  with  the  TIBs  to 
generate  flat  (unstructured)  files,  which  provided  a  simulated  I&W  data 
base  which  was  not  specifically  tailored  for  any  one  of  the  DBMSs  to  be 
tested.  The  TIBs  specified  the  range  and  distribution  of  data  within  each 
field.  The  DBG  randomly  selected  values  to  be  placed  in  the  data  base, 
within  the  range  and  with  the  distribution  specified  by  the  TIBs.  Thus, 

while  the  data  are  composed  simply  of  random  values,  they  have  the 

statistical  characteristics  of  a  realistic  I&W  data  base.  This  approach 
permitted  the  construction  of  a  data  base  which  would  provide 
statistically  valid  tests  of  the  DBMSs  without  the  high  labor  costs  and 
security  considerations  involved  in  implementing  an  I&W  data  base  with 
real  data. 

Figure  4-1  represents  a  blank  TIB  form.  Numbers  appearing  on  the  form 
correspond  to  numbers  in  the  descriptions  given  below. 

1 .  Sheet  numbers  refer  to  those  required  for  the  complete 
specification  of  one  TIB. 

2.  The  TIB  Number  is  the  identification  code. 

3.  The  Specification  Number  identifies  the  particular  specification 
statement. 


The  purpose  or  use  is  an  explanation  of  the  context  within  which 
the  TIB  occurs,  and  the  reason  for  its  occurrence  in  the  form 
shown. 

The  number  of  unique  occurrences  of  the  TIB  refers  to  the  total 
count  of  all  TIB  occurrences  which  are  associated  with  the  given 
specification. 

The  TIB  item  number. 

The  access  use: 

"G"  Grouping  item. 

"E"  Entry  item  or  key.  (Occasionally,  "El"  and  "E2"  are  used. 
These  refer  to  entry  keys  which  are  a  combination  of  the  items 
marked,  taken  in  the  order  numbered.) 

Size  and  structure  information. 

The  specific  value  to  be  used  in  this  specification. 

The  number  of  occurrences  of  the  TIB  in  which  the  particular 
value  stated  will  occur. 

The  total  number  of  different  and  unique  values  which  the  given 
TIB  item  can  be  expected  to  take,  within  the  context  of  the 
TIBts  functional  use.  This  information  is  given  only  for  entry 
and  key  items. 

Remarks  cover  any  extra  information  required  for  the 
specification.  Of  particular  importance  here  is  the  statement  of 
the  number  of  occurrences  of  a  subblock  to  be  expected  for  one 
occurrence  of  a  header  block. 
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The  procedures  used  for  the  test  data  base  specification  were  developed 
following  recommendations  contained  in  the  Betac  report,  "Application  of 
Data  Base  Specification  Procedures  of  the  I&W  Data  Base  Generation,"  30 
September  1981.  The  procedures  used  for  determination  of  the  values  and 
distribution  of  values  In  the  I&W  data  base  were  as  follows: 

o  For  each  item  in  the  TIBs,  estimate  its  expected  value,  range  of 
values,  and  distribution  of  values,  based  on  the  Betac  report. 

o  Taking  into  account  the  scenarios  to  be  implemented  in  the 
Benchmark  Tests,  select  specific  values  to  support  the 
activities  described  in  the  scenarios. 

Two  types  of  files  were  built,  using  the  line  editor,  as  input  to  the  Data 
Base  Generator  (DBG)  program: 

o  •.TIB  files.  These  contain  the  name  of  the  TIB,  number  of 

records,  number  of  blocks,  and  specific  values  of  each  item. 

o  •.TAB  files.  These  contain  the  number  of  occurrences  of  the 
miscellaneous  table  driven  constants. 

The  •.TIB  and  •.TAB  files  were  used  as  input  to  the  DBG  program  to  produce 
flat-file  representations  (i.e.  unstructured  files)  of  the  data  base. 

The  exact  format  of  the  files  to  be  used  by  the  loader  was  different  for 
each  DBMS.  For  ADABAS-M  a  conversion  program,  ADACNV ,  was  written  to 
convert  output  files  produced  by  the  DBG  into  the  required  format  for  the 
ADABAS-M  loader. 
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Values  generated  by  the  DBG  were  then  checked  to  ensure  that  the  generated 
data  actually  met  the  TIB  specifications.  A  number  of  errors  were  detected 
and  corrected  through  the  use  of  small  utility  programs.  In  general,  these 
errors  were  failures  to  generate  special  values  required  by  some  of  the 
scenarios.  (Errors  were  detected  and  corrected  in  files  B1 ,  Cl,  D1 ,  D2, 
El ,  and  E2 . )  These  programs  used  the  flat  files  produced  by  the  DBG 
program  as  input,  and  corrected  or  modified  the  faulty  fields  before  they 
were  passed  to  ADACON,  the  conversion  program  for  reformatting  the  data 
into  the  format  desired  for  the  ADABAS-M  loader. 

As  pointed  out  earlier,  a  number  of  small  corrector  programs  were  cycled 
against  the  intermediate  versions  of  the  data  base  before  it  was  loaded 
for  ADABAS-M.  It  was  deemed  more  re source- effective,  in  both  time  and 
manpower,  to  download  the  data  base  from  ADABAS-M  and  reformat/convert  the 
files  into  the  formats  required  by  the  high-speed  load  facilities  of 
ORACLE  and  SEED.  The  advantage  to  this  approach  was  twofold: 

o  Each  item  in  the  data  base  for  each  DBMS  has  exactly  the  same 
value.  Any  error  in  value  present  in  the  data  base  for  ADABAS-M  will  also 
be  present  for  ORACLE  and  SEED. 

o  The  approach  was  more  cost  effective.  Due  to  the  size  and 
complexity  of  the  files  in  the  data  base,  a  number  of  long-running  Jobs 
utilizing  some  very  large  intermediate  files  were  necessary  to  build  each 
file.  Some  of  these  large  intermediate  files  could  not  reside  on  the  same 
disk  pack,  necessitating  numerous  mounts  and  dismounts  of  disk  packs 
during  the  course  of  building  the  data  base. 
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This  section  describes  the  Early  Wurning  and  Monitoring  System  (EWAMS) 
data  base,  which  is  derived  from  the  World  Evontu/Interaction  Series 

(WEIS)  data  base.  The  WEIS  data  base  originally  used  the  New _ York  IlBfifl 

its  sole  source  but  has  since  added  The  Times  of  London  and  the  Lfifl 

Timea  as  additional  sources  of  data.  The  New  York  Times  is  the 

principal  source,  and  the  other  two  papers  are  usod  as  supplementary 
sources,  to  check  reliability  and  validity  [McClelland,  Charles  A., 
"D-Filcs  for  Monitoring  and  Forecasting  Threat  and  Dangerous  Problems 
Abroad."  Paper  presented  at  the  Annual  Meeting  of  the  International 
Studies  Association,  Washington  DC,  March,  1978].  EWAMS  also  uses  Xbfi. 
Guardian  of  Manchester  as  a  source. 

Events  from  these  papers  are  put  into  one  of  63  different  categories.  In 
order  to  facilitate  uniform  coding,  these  63  categories  are  ordered  and 
subdivided  into  22  groups.  Each  of  the  22  groups  is  headed  by  a  cue-word. 
The  cue-words  are  not  intended  to  have  their  exact  common-language 
meanings,  but  are  technical  mnemonic  devices  only.  Examples  of  the 

cue-words  are:  YIELD,  COMMENT,  CONSULT,  and  APPROVE.  Under  each  of  the 

cue-words  are  listed  one  or  more  categories,  each  of  which  is  given  a 
numerical  code.  For  example,  looking  under  the  third  cue-word,  CONSULT, 
one  would  find: 

3.  CONSULT 

031  Meet  with  at  neutral  site;  or  send  note; 

stay  in  same  place 
032  Visit;  go  to;  leave  country 
033  Receive  visit;  host 
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(See  Table  6-1  for  a  complete  listing  of  the  categories  and  their  codes. 
See  also  Table  6-2  for  a  listing  of  the  Conflict  Area  Codes,  and  Table  6-3 
for  a  listing  of  the  Actors  Codes.) 

In  addition  to  the  code  for  63  actions,  there  is  a  numerical  code  for  the 
participants  in  the  interactions.  The  originator  of  each  action  is  called 
an  "actor,"  and  the  recipient  is  termed  a  "target."  These  actors  and 
targets  include  both  independent  nations  and  international  organizations 
and  groups,  such  as  NATO  and  the  European  Common  Market.  For  example,  002 
is  the  code  for  the  United  States,  395  for  Iceland,  and  396  for  NATO.  With 
this  coding,  event  interactions  may  be  concisely  represented  in  the  data 
base.  For  example,  if  the  United  States  deployed  naval  vessels  to  protect 
American  fishing  boats  near  Icelandic  waters  from  harassment,  the  event 
would  be  encoded: 


002  223  395 

where  223  is  the  code  for  "military  engagement."  Actually,  the  encoded 
message  in  the  WEIS  data  base  would  also  include  code  for  date,  coder, 
collection  number,  and  item  identification  number.  It  would  look  like 
this: 

83  07  18  002  223  395  00  25  990001 

The  numbers  give  the  year,  month,  day,  actor,  event,  target,  source, 
coder,  and  an  item  identification  number.  It  is  important  to  note  that  the 
encoded  message  would  be  identical  if  the  United  States  had  launched  a 
massive  nuclear  attack  on  Iceland.  The  intensity  and  the  context  of  the 
interaction  are  ignored  in  the  WEIS  data  base.  It  is  assumed  that  the 
number  of  messages  will  provide  a  rough  measure  of  the  intensity  of  the 
interaction. 
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FIN 

FRN 


Finland 

France 


AFG  Afghanistan 
ALB  Albania 

ALG  Algeria 

AND  Andorra 

ARG  Argentina 

AUL  Australia 

AUS  Austria 


BAR 

BEL 

EBE 

WBE 

BOL 

BOT 

BRA 

BUL 

BUR 

BUI 


Barbados 

Belguim 

Berlin/East 

Berlin/West 

Boliva 

Botswana 

Brazil 

Bulgaria 

Burma 

Burundi 


CAM  Cambodia 

CAO  Caiaeroun 

CAN  Canada 

CEN  Central  African  Rep. 

CEi  Ceylon 

CHA  Chad 

CHL  Chile 

CHN  China,  People's  Rep. 

CHT  China,  Rep.  of 

COL  Columbia 

CON  Congo  (Brazzaville) 

COP  Congo  (Kinshasa) 

COS  Costa  Rica 

CUB  Cuba 

CYP  Cyprus 

CZE  Czechoslovakia 


DAH 

DEN 

DOM 


Dahomey 
Denmark 
Dominican  Rep. 


ECU  Equador 

ELS  El  Sal vador 

GUE  Equitorial  Guinea 

(incl.  Fernando  Po) 
ETH  Ethiopia 


37  5 
220 

i*8l 

420 

265 

255 

1452 

350 

090 

438 

110 

041 

091 

310 

720 


051 

740 

663 


I  J 

II 


501 
731 
2 
90 

812 

660 

570 

450 

620 

223 

212 


GAB 

GAM 

GME 

GMW 

GHA 

GRC 

GUA 

GUI 

GUY 

HAI 

HON 

HUN 

HOK 

ICE 

IND 

INS 

IRN 

IRQ 

IRE 

ISR 

ITA 

IVO 

JAM 

JAP 

JOR 

KEN 

KON 

KOS 

KUW 

LAO 

LEB 

LES 

LBR 

LBY 

LIC 

LUX 
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Gabon 

Gambia 

Germany/Dem . Rep 

Germany/Fed. Rep 

Ghana 

Greece 

Guatemala 

Guinea 

Guyana 

Haiti 
Honduras 
Hungary 
Hong  Kong 

Iceland 

India 

Indonesia 

Iran 

Iraq 

Ireland 

Israel 

Italy 

Ivory  Coast 

Jamaica 

Japan 

Jordan 

Kenya 

Korea/ North 
Korea/ South 
Kuwait 

Laos 

Lebanon 

Lesotho 

Liberia 

Libya 

Liechtenstein 

Luxemburg 
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MAC 

Macao 

510 

TAZ 

Tanzania 

MAG 

Malagasy 

800 

TAI 

Thailand 

MAW 

Malawi 

1161 

TOG 

Togo 

Trinidad-Tobago 

Tunisia 

MAL 

MAD 

Malaysia 

Maidive 

052 

616 

TRI 

TUN 

Mali 

640 

TUR 

Turkey 

Malta 

MAR 

Mauritius 

500 

UGA 

Uganda 

MAU 

Mauritania 

365 

651 

USR 

USSR 

MEX 

Mexico 

UAR 

UAR  (Egypt) 
United  Kingdom 

MOC 

Monaco 

200 

UNK 

MON 

Mongolia 

002 

USA 

USA 

MOR 

Morocco 

439 

UPP 

Upper  Volta 

MOM 

Muscat  and  Oman 

165 

URU 

Uruguay 

NAU 

Nauru 

328 

VAT 

Vatican 

NEP 

NTH 

Nepal 

Netherlands 

101 

817 

VEN 

VTS 

Venezuala 
Vietnam/ South 

NEW 

New  Zealand 

816 

VTN 

Vietnam/North 

NIC 

Nicaragua 

NIR 

Niger 

990 

WSM 

Western  Samoa 

NIG 

Nigeria 

NOR 

Norway 

678 

681 

YEM 

Yemen 

SYE 

Yemen/South 

PAR 

Pakistan 

345 

YUG 

Yugoslavia 

PAN 

Panama 

PAR 

Paraguay 

551 

ZAM 

Zambia 

PER 

Peru 

PHI 

Philippines 

Non- 

■Governmental  Actors 

POL 

Poland 

198 

POR 

Portugal 

AFP 

Alliance  for 
Progress 

RHO 

Rhodesia 

*?t 

ARL 

Arab  League 

RUM 

Rumania 

BIA 

Biafra 

RWA 

Rwanda 

397 

398 

EEC 

Common  Market 

EFT 

EFTA 

SAN 

San  Marino 

396 

199 

NAT 

NATO 

SAU 

Saudi  Arabia 

OAS 

OAS 

SEN 

Senegal 

599 

0AU 

OAU 

SIE 

Sierra  Leone 

697 

PLO 

Arab  Commando 

SIN 

SOM 

Singapore 

Somalia 

813 

LAP 

groups 

Pathet  Lao 

SAF 

South  Africa 

292 

SEA 

SEATO 

SPN 

Spain 

818 

VCG 

Vietcong  and 

SUD 

Sudan 

394 

NLF 

SWA 

Swaziland 

WAR 

Warsaw  Pact 

SWD 

Sweden 

SWZ 

Switzerland 

399 

UNO 

Any  inti.  org. 

SYR 

Syria 

998 

MLG 

Any  multi¬ 
lateral  group 

999 

NSC 

Not  stated,  un¬ 
identified 
target 
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YIELD 

Oil  Surrender,  yield  to  order,  submit  to  arrest,  etc. 

012  Yield  position;  retreat;  evacuate 
013  Admit  wrongdoing;  retract  statement 

COMMENT 

021  Explicit  decline  to  comment 
022  Comment  on  situation — pessimistic 
023  Comment  on  situation — neutral 
024  Comment  on  situation — optimistic 
025  Explain  policy  or  future  position 

CONSULT 

031  Meet  with  at  neutral  site;  or  send  note;  stay  in  same  place 
032  Visit;  go  to:  leave  country 
033  Receive  visit;  host 

APPROVE 

041  Praise,  hail,  applaud,  condolences,  ceremonial  greetings,  thanks 
042  Endorse  others  policy  or  position,  give  verbal  support 

PROMISE 

Q51  Promise  own  policy  support 
052  Promise  material  support 
053  Promise  other  future  support  action 
054  Assure;  reassure 

GRANT 

061  Express  regret:  apologize 
062  Give  state  invitation 
063  Grant  asylum 

064  Grant  privilege,  diplomatic  recognition;  de  facto  relations,  etc. 
065  Suspend  negative  sanctions;  truce 
066  Release  and/or  return  persons  or  property 

REWARD 

071  Extend  economic  aid  (gift  and/or  loan) 

072  Extend  military  assistance;  joint  military  exercises 
073  Give  other  assistance 

AGREE 

081  Make  substantive  agreement 

082  Agree  to  future  action;  agree  to  meet,  negotiate;  accept  state 
invitation 
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9.  REQUEST 


091  Ask  for  information 

092  Ask  for  policy  assistance;  seek 

093  Ask  for  material  assistance 

094  Request  action;  call  for;  ask  for  asylum 

095  Entreat;  plead  for;  appeal  to;  help 

10.  PROPOSE 

101  Offer  proposal 

102  Urge  or  suggest  action  policy 

11.  REJECT 

111  Turn  down  proposal:  reject  protest  demand,  threat,  etc. 

112  Urge  or  suggest  action  or  policy 

12.  ACCUSE 

121  Charge;  criticize:  blame;  disapprove 

122  Denounce;  denigrate;  abuse;  condemn 

13-  PROTEST 

131  Make  complaint  (not  formal) 

132  Make  formal  complaint  or  protest 

111.  DENY 

1i»1  Deny  an  accusation 

1 42  Deny  an  attributed  policy,  action,  role,  or  position 

15.  DEMAND 

150  Issue  order  or  command,  insist;  demand  compliance,  etc. 

16.  WARN 

17.  THREATEN 

171  Threat  without  specific  negative  sanctions 

172  Threat  with  specific  non-military  negative  sanctions 

173  Threat  with  force  specified 

175  Ultimatum;  threat  with  negative  sanctions  and  time  limit 
specified 

18.  DEMONSTRATE 

181  Non-military  demonstration;  walk  out  on;  boycott 

182  Armed  force  mobilization,  exercise,  and/or  display 
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19.  REDUCE  RELATIONSHIP  (As  Negative  Sanction) 

1Q1  Cancel  or  postpone  planned  event 

192  Reduce  routine  international  activity;  recall  officials,  etc. 

193  Reduce  or  suspend  aid  or  assistance 

194  Halt  negotiations 

195  Break  diplomatic  relations 

20.  EXPEL 

201  Order  personnel  out  of  country;  deport 

202  Expel  organization  or  group 

21.  SEIZE 

211  Seize  position  or  possessions 

212  Detain  or  arrest  person(s) 

22.  FORCE 

221  Non-injury  destructive  act;  bomb  with  no  one  hurt 

222  Non-military  injury-destruction 

223  Military  engagement 
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CODE 


CONFLICT  ARENA 


010  Arab-Israeli  conflict  (general) 

013  19o7  war  (all  Mideast  events  during  1967) 

020  Vietnam  talks  in  Paris 

025  1968  Vietnam  talks  in  Paris 

027  Military  engagements  as  of  October  1969  (Vietnam) 

030  Rhodesian  independence 

040  Berlin  conflict 

050  Sino-Soviet  conflicts 

066  Indonesla-Malaysia  disputes 

076  India-China  conflicts 

080  USA-China  conflicts 

090  India-Pakistan  disputes 

100  Cyprus 

110  Korean  conflicts 

120  France-NATO  dispute 

130  West  German-East  Europe  dispute 

150  Dominican  Republic 

160  Red  Guard  activities 

170  Czechoslovakia-Soviet  Union 

180  Biafra-Nigeria  conflict 

190  Strategic  Arms  Limitation  Talks 

200  Non-Government-Sanctioned  Violence 

(e.g. ,  kidnappings,  hijackings,  etc.) 

210  Cambodian  conflict 


From  C.A.  McClelland,  et  al  "The  Management  and  Analysis  of 
International  Event  Data:  A  Computerized  System  for  Monitoring 
and  Projecting  Event  Flows",  1971. 
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In  addition  to  actor,  event,  and  target  codes,  there  are  arena  codes  that 
denote  areas  that  are  of  particular  interest.  This  feature  allows  the  user 
of  the  data  base  to  extract  all  data  pertinent  to  a  particular 
international  occurrence,  e.g.  the  Vietnam  conflict,  or  the  India-China 
conflicts.  This  code  would  follow  the  target  code.  Thus  one  would  encode 
the  event  of  India's  protesting  China's  deployment  of  troops  near  India' 3 
border  as: 

71  07  18  750  313  710  070  00  25  990002 

where  the  first  three  entries  are  the  date,  750  is  the  code  for  India,  3 1 3 
is  the  code  for  an  informal  complaint,  710  is  the  code  of  the  People's 
Republic  of  China,  and  070  is  the  code  for  India-China  conflicts.  [C.  A. 
McClelland  et  al.,  "The  Management  and  Analysis  of  International  Event 
Data:  A  Computerized  System  for  Monitoring  and  Projecting  Event  Flows," 
World  Event/Interaction  Survey  Technical  Report,  Los  Angeles:  University 
of  Southern  California,  Sept.  1971.] 

For  implementation  and  demonstration  during  this  project,  a  subset  of  the 
records  in  the  EWAMS  data  base  were  expanded  to  include  latitude  and 
longitude  of  each  event.  In  this  way,  the  location  of  the  event  could  be 
used  in  a  map  display  of  world  events,  and  could  be  used  to  retrieve 
messages  in  a  selected  area. 

The  WEIS  data  base  consists  of  two  parts.  In  addition  to  the  coded  portion 
of  the  data  base  discussed  above,  there  is  another  section  of  the  WEIS 
data  base  that  contains  a  brief  English  language  summary  of  each  coded 
interaction.  These  "messages"  were  also  used  in  demonstrations  of  the 
DBMSs. 
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A  detailed  scenario  describing  events  related  to  the  Libyan  crisis  of  1981 
was  produced  by  Betac.  Only  unclassified  data  were  used  in  generating  the 
scenario  and  supporting  material.  The  source  of  most  of  this  information 
was  the  daily  Foreign  Broadcast  Information  Service  (FBIS)  reports 
published  by  the  U.S.  Government.  These  reports  are  issued  in  editions 
covering  each  of  the  world's  major  regions,  and  containing  extracts  from 
broadcasts  of  radio  stations  and  from  newspapers  of  the  regions.  This  test 
exercise  of  the  I&W  DBMS  uses  the  Middle  East  and  Africa  daily  reports. 
The  entries  for  Libya  and  those  concerned  with  Libyan  affairs  and  events 
listed  under  other  nations  in  the  region  from  1  July  1981  to  1  October 
1981  were  reviewed  for  possible  correlation  with  items  contained  in  an  ad 
hoc  set  of  Middle  East  indicators  formerly  used  by  DIA. 

The  FBIS  information  was  used  as  the  basic  data  source  for  several 
reasons.  First,  it  provides  an  unclassified  ongoing  source  of  data  for  a 
specific  nation  or  geographic  area.  This  information  is  of  greater  breadth 
and  volume,  and  of  more  detail  for  individual  countries,  than  standard 
newspapers  or  journals  published  in  other  English  language  sources.  In 
addition,  its  natural  focus  tends  to  be  upon  articles  reflecting  I&W 
concerns.  The  FBIS  data,  then,  provide  an  equivalent  to  the  stream  of 
messages  with  which  an  intelligence  analyst  might  have  to  deal  while 
manning  a  position  in  an  I&W  center. 

In  the  suggested  exercise  of  the  data  base,  the  analyst  would  be 
attempting  to  determine  the  present  level  of  threat  to  various  American 
activities  in  the  region  that  occur  within  the  operational  area  of  a  given 
nation's  armed  forces  and  weapon  systems.  In  this  case  the  specified 
nation  is  Libya.  The  analyst  is  also  attempting  to  determine  any  changes 
in  threat  level  which  new  events  relating  to  Libya  may  indicate.  The 
following  summary  provides  an  outline  of  the  material  contained  in  the 
Libyan  scenario. 
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The  scenario  represents  the  perception  of  the  threat  presented  by  Libya  to 
U.S.  forces,  citizens,  and  interests,  based  on  recent  Near  Eastern  and 
Middle  Eastern  events.  The  analyst  would  presumably  have  knowledge  of  the 
U.S.  Navy  maneuvers  taking  place  in  the  Gulf  of  Sidra  during  August  1981. 
The  first  alert  message,  or  one  that  would  cause  the  analyst  to  feel 
increased  concern  over  U.S.  activities  in  the  area,  is  a  warning  statement 
from  the  Libyan  government  threatening  the  U.S.  Navy  exercise.  This  is 
followed  by  a  report  of  the  actual  air  clash,  with  later  reports  of 
reactions  to  the  clash.  These  include  condemnation  of  the  U.S.  action  in 
the  press  by  several  Arab  countries,  including  some  at  least  nominally 
friendly  to  the  U.S.  Some  of  these  articles  call  for  punishment  of  the 
U.S.  and  a  unified  stand  in  support  of  Libya. 

In  terms  of  further  threats  to  the  U.S.  or  to  U.S.  activities  in  the  area, 
the  analyst  would  note  that  Colonel  Qaddhafi  is  again  threatening  to  join 
the  Warsaw  Pact  and  possibly  to  allow  the  Soviets  to  have  basing  rights  in 
Libya.  At  the  same  time,  Qaddhafi  also  threatens  to  attack  NATO  bases  in 
Southern  Europe,  should  the  U.S.  again  "attack"  Libyan  forces.  The  analyst 
also  finds  an  item  stating  that  the  Libyans  have  Soviet  made  medium-range 
missiles  that  could  reach  Southern  European  NATO  bases  from  launch  sites 
in  Libya. 

In  several  reports  which  are  possibly  related,  the  analyst  finds  that 
there  have  been  defections  of  Libyan  diplomats  in  posts  around  the  world. 
If  they  can  be  used  an  as  indication  of  increased  dissention  within  the 
Libyan  government  over  policies  of  the  ruling  group,  one  might  surmise 
that  incidents  such  as  the  19  August  air  battle  could  have  been 
precipitated  by  the  Libyan  government  in  order  to  create  a  public 
perception  of  an  external  threat,  thus  aiding  in  quelling  dissension  by 
appealing  to  a  need  for  national  unity.  This  may  also  mean  that  further 
incidents  can  be  expected  if  the  desired  effect  is  not  produced  by  the 
initial  incident  or  if  the  feeling  of  national  unity  is  to  be  maintained 
at  a  high  pitch  over  an  extended  period  of  time. 


Overall,  then,  the  analyst  sees  a  violent  incident  occurring  quite 
suddenly,  followed  by  a  strong  reaction  from  the  Libyan  government. 
Whether  or  not  the  Libyan  government  deliberately  initiated  the  incident, 
it  appears  from  their  reaction  that  they  were  genuinely  frightened  by  the 
possibility  of  further  incidents.  The  result  was  what  could  be  the 
strongest  anti-U. S.  threats  by  the  Libyans  to  date.  The  nature  of  these 
threats  —  especially  those  directed  toward  U.S.  nuclear  weapons 
stockpiled  at  Southern  European  NATO  bases  —  and  the  degree  of  support 
for  Libyan  retaliation  exhibited  by  some  of  the  more  moderate  Arab  states 
may  cause  the  analyst  to  focus  his  efforts  on  Libyan  threats  as  very 
serious  short  term  or  intermediate  term  disruptive  factors  in  the  Near 
East  and  Mediterranean  area. 

In  this  scenario,  the  analyst  performs  a  sequence  of  operations  that  could 
be  partially  supported  by  a  DBMS: 

o  Background  information  is  retrieved  concerning  U.S.  Navy 
Maneuvers  in  the  Gulf  of  Sidra. 

o  A  statement  from  the  Libyan  government  concerning  the  maneuvers 
is  perceived  as  a  threat.  In  other  words,  the  statement  must  be 
interpreted  in  such  a  way  as  to  indicate  its  relevance  for  the 
analyst. 

o  A  report  concerning  the  air  clash  must  be  correlated  with 
reports  of  reactions  to  the  clash.  The  event  gains  in 
signficance  as  these  additional  reports  are  clustered  with  the 
original  report. 

o  The  fact  that  some  of  the  condemnations  come  from  friendly 

nations  is  more  signficant  that  the  routine  condemnations  from 
hostile  nations. 
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Qaddhafi's  repeated  threats  to  join  the  Warsaw  Pact  must  be 
correlated  with  the  developing  picture  of  the  situation. 
Historical  information  concerning  earlier  threats  of  this  type 
should  be  retrieved  automatically,  to  supplement  current 
information. 

The  system  should  have  some  means  of  relating  the  potential 
crisis  to  the  earlier  defections  of  Libyan  diplomats.  It  should 
be  possible  to  see  that  these  defections  can  be  taken  as  a 
possible  cause  of  the  violent  reaction  to  the  U.S.  activities, 
and  to  hypothesize  that  the  Libyan  government  might  have 
initiated  the  incident. 

The  system  should  be  capable  not  only  of  evaluating  but  of 
characterizing  the  threat  in  detail,  and  of  providing  an 
explanation  of  the  reasoning  that  lies  behind  its  evaluation. 


By  isolating  specific  requirements  such  as  these,  the  Libyan  scenario 
provides  the  basis  for  recommending  further  enhancements  and  extensions  to 
the  I&W  DBMS. 
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Schema  definitions  were  prepared  in  the  forms  required  by  each  of  the 
three  DBMSs.  In  theory,  it  should  have  been  possible  to  load  the  flat 
files  directly  onto  disk,  in  the  specified  formats,  using  the  bulk  loader 
facilities  of  the  DBMSs.  In  actuality,  the  process  was  more  complex.  For 
ADABAS-M,  it  was  necessary  to  prepare  special  programs  to  transform  the 
data  base  into  formats  which  were  acceptable  to  the  ADABAS-M  loader.  The 
transformed  data  were  also  used  with  the  ORACLE  loader.  Preparation  of 
schema  definitions  for  SEED  proved  to  be  considerably  more  difficult  than 
for  the  other  DBMSs,  and  only  a  subset  were  loaded.  In  general,  the  size 
of  the  data  base  required  to  support  the  I&W  scenarios  was  several  times 
larger  than  the  capacity  of  the  two  RP06  disk  drives  available,  and 
subsets  were  used  for  the  actual  testing. 

A  listing  of  the  files  actually  implemented  is  contained  in  Section  12.0 
of  this  report.  Detailed  schema  definitions  are  being  supplied  with 
program  documentation  for  this  project. 


Remote  Terminal  Emulation  (RTE)  testa  were  monitored  by  the  General 
Purpose  Monitor  (GPM),  a  software  tool  developed  by  Mc^  under  RADC 
Contract  No.  F30602-80-C-0277.  The  GPM  will  be  described  in  this  section. 

The  GPM  is  an  evaluation  tool  which  measures  system  activities  and 
produces  summary  reports  for  use  in  assessing  system  performance.  Two 
goals  in  the  design  and  implementation  of  the  GPM  were: 

o  Low  system  artifact  (that  is,  the  GPM  should  require  a  minimum 
of  system  resources  for  its  own  operation). 

o  Zero  system  endangerment  (that  is,  operation  of  the  GPM  must  not 
cause  failures  of  the  system  under  test). 

In  meeting  these  objectives,  the  GPM  was  designed  to  operate  externally  to 
the  system  under  test,  observing  its  behavior  from  the  outside.  This 
approach  does  not  require  user  modification  of  the  program  code,  through 
the  insertion  of  probes,  counters,  flags,  and  the  like.  Instead,  the  GPM 
operates  by  modifying  Operating  System  code  to  support  monitoring  of 
various  conditions  at  appropriate  times  during  system  activities.  The 
types  of  data  collected  depend  upon  the  options  selected  by  the  user. 

Ir  addition  to  response  time,  which  can  be  measured  indirectly  by  the  GPM, 
the  monitor  has  the  ability  to  collect  data  relating  to  the  following 
activities: 

o  Emulated  Traps  (EMTs)  executed  by  the  system 

o  Send/Receive  Directives 

o  Queue  Inputs/Outputs  (QIOs)  by  task  and  devices 


c  Task  Execution  Directives 


o  Exit  and  Suspend  Directives 


o  Trap,  Informational,  and  Status  Directives 


o  I/O  to  files 


o  Block  Counts  of  data  to  and  from  devices 


o  Null  Task  times 


o  Operating  System  Service  time 


o  Task  statistics  and  idle  time 


o  Node  Pool  use 


o  Disk  Arm  Movement 


The  GPM  is  described  in  more  detail  in  Appendix  E. 
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10.0  general  description  of  systems  tested 


This  section  describes  characteristics  of  the  three  systems  under  test, 
ADABAS-M,  ORACLE,  and  SEED.  The  purpose  of  this  section  is  to  provide  the 
reader  with  a  fairly  detailed  picture  of  the  systems,  emphasizing  those 
features  that  would  be  significant  in  a  particular  application. 

The  three  systems  represent  three  approaches  to  data  base  system  design: 
indexed,  relational,  and  network.  Within  these  approaches,  each  of  the 
systems  contains  features  which  make  it  more  or  less  applicable  to  an 
individual  installation.  There  is  no  system  that  is  best  at  everything. 

10.1  ADABAS-M  Charateristics 

As  noted  elsewhere  in  this  report,  ADABAS-M  was  developed  by  the  vendor, 
Software  AG,  for  use  on  DEC  computer  equipment.  It  is  not  an  adaptation 
of  the  widely-used  ADABAS  system.  Errors  in  the  implementation  have  led 
the  vendor  to  withdraw  the  ADABAS-M  implementation  from  further  sale.  The 
system  was  nevertheless  efficient  and  easily-used.  It  should  certainly  be 
considered  for  I4W  applications  when  and  if  it  returns  to  the  market. 
Although  the  technology  upon  which  it  is  based  is  some  twenty  years  old, 
ADABAS-M  can  perform  well  for  many  users.  The  use  of  indexes  provides  very 
rapid  access  to  data  items  when  the  keys  are  known,  but  non-keyed  items 
can  be  retrieved  only  through  the  use  of  specially  written  programs,  and 
retrieval  is  much  slower. 

Like  the  other  systems,  ADABAS-M  provides  a  full  range  of  update/ load 
components:  the  ability  to  modify  and  edit  individual  data  items  within  a 
selected  record,  the  ability  to  add  or  delete  individual  records,  and  the 
ability  to  load  large  amounts  of  data  from  non-DBMS  files  into  DBMS  files 
through  a  bulk-load  facility.  In  addition,  ADABAS-M  can  use  relational  and 
Boolean  operators  to  qualify  records  for  modification  or  deletion.  A  host 
language  has  the  ability  to  perform  update/load  functions  from  a 
programming  language.  Loaders  are  available  for  both  initial  and 
incremental  load.  A  sort  utility  is  included  in  the  loader  package. 


All  three  systems  provide  a  range  of  query  and  report  facilities.  ADABAS-M 
has  the  ability  to  perform  query  and  report  functions  from  a  programming 
language.  It  can  use  relational  and  Boolean  operators  to  qualify  records 
and  data  items  for  retrieval.  Functions  for  producing  summaries  are  also 
provided.  Applications  programs  must  be  used  for  testing  non-indexed  field 
values.  ADABAS-M  includes  facilities  for  phonetic  retrieval,  which  might 
be  useful  for  some  IAW  files  (e.g.  biography  files)  where  the  exact 
spelling  is  not  known. 

ADABAS-M,  like  the  other  systems,  includes  a  range  of  facilities  for 
restart  and  recovery.  It  maintains  an  audit  log  which  can  record  all 
transactions  made  to  the  data  base.  It  is  also  capable  of  dumping  the 
contents  of  the  entire  data  base  files  onto  removable  storage  (e.g.  disk) 
and  copying  the  contents  of  a  dump  into  the  data  base  files.  Checkpoint, 
rollback,  and  rollforward  facilities  are  provided.  The  system  can 
reconstruct  the  data  base  from  a  known  consistent  state  (checkpoint)  after 
a  system  crash,  by  rolling  committed  transactions  forward  and  uncommitted 
transactions  backward.  ADABAS-M  provides  utilities  for  transferring  the 
disk  log  onto  tape. 

ADABAS-M  provides  facilities  for  protecting  data  security,  including  the 
ability  to  authorize  selective  access  to  a  file,  set,  record,  or  data 
item.  Read-only  and  write  permissions,  including  add,  delete,  and  update 
operations,  can  be  specified. 

A  full  range  of  concurrency  controls  are  also  provided.  Multiple  users  may 
access  the  same  collection  of  data,  such  as  a  file  or  set.  Multi-user 
facilities  are  provided.  Multi-threading,  the  ability  to  overlap  service 
requests  to  secondary  data  storage  devices,  is  also  provided.  ADABAS-M 
handles  up  to  128  threads. 

All  three  systems  provide  facilities  for  data  definition.  ADABAS-M 
provides  a  schema  capability  to  define  the  logical  structure  of  the  data 
base,  as  well  as  the  physical  organization,  format,  and  validation 
criteria  for  the  data.  In  addition,  all  systems  provide  for  subschemas,  or 
user  views,  corresponding  to  user  applications.  In  ADABAS-M,  indexes  can 
be  dynamically  created  or  dropped. 
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All  systems  under  test  are  capable  of  physically  rearranging  data  for 
increased  access  efficiency  and  reduced  data  volume.  ADABAS-M  provides 
monitoring  subfunctions,  including  the  ability  to  determine  and  report  on 
the  status  of  the  DBMS  files,  such  as  the  number  of  records,  the  percent 
filled,  etc.,  and  the  ability  to  determine  and  report  on  the  current 
status  and  performance  of  the  system,  such  as  the  number  of  users,  number 
of  I/Os,  etc. 

ADABAS-M  compares  favorably  with  the  other  systems  in  the  size  of  the  data 
base  supported  and  its  ability  to  accommodate  large  data  bases  and 
multi-volume  files.  Memory  resources  required  by  ADABAS-M  are  the  smallest 
among  the  three  systems  tested,  with  only  32K  words  needed.  In  terms  of 
system  cost,  ADABAS-M,  at  about  $38,000,  was  somewhat  lower  in  price  than 
ORACLE  ($48,000),  but  more  expensive  than  SEED  ($14,000). 

ADABAS-M  provides  a  full  range  of  documentation,  including  user  manual, 
operator  manual,  programming  manual,  and  training  materials.  Training, 
provided  on-site,  included  a  competent  company  representative  with 
appropriate  instructional  materials. 

In  terms  of  portability,  ADABAS-M  is  the  least  portable  of  the  three 
systems  tested,  since  it  was  programmed  in  assembly  language  for  DEC 
equipment.  It  is  important  to  remember  that  ADABAS-M  is  not  the  same 
system  as  ADABAS,  which  is  tailored  to  IBM  equipment. 

In  Mc^'s  initial  evaluation,  summarized  here,  ADABAS-M  received  the 
highest  score  of  all  the  systems  rated.  However,  the  scores  of  all  three 
systems  under  te3t  were  quite  similar.  ADABAS-M  was  given  high  scores  for 
its  update/load  facilities,  large  data  base  capacity,  concurrency 
controls,  and  monitoring  capability.  It  was  given  a  somewhat  lower  rating 
for  its  lack  of  portability. 


1 0-1 


ORACLE,  distributed  by  Relational  Software  Incorporated,  is  a  relatively 
new  system  exploiting  the  relational  data  model  developed  by  E.  F.  Codd 
["A  Relational  Model  of  Data  for  Large  Shared  Data  Banks,"  Communications 
of  the  ACM,  13:6  (June  1970)].  The  system  tested  was  ORACLE  2.3,  whioh  was 
replaced  during  1982  by  ORACLE  3.0.  ORACLE  3.0  is  said  to  be  a  more 
efficient  implementation  of  the  model. 

ORACLE  provides  all  standard  update  and  load  facilities,  including  the 
ability  to  modify  and  edit  data,  add  and  delete  data  items,  perform  a  bulk 
load,  and  use  relational  and  Boolean  operators  in  specifying  items  for 
update  and  load.  A  host  language  interface  permits  the  user  to  perform 
update  and  load  functions  from  an  application  program. 

ORACLE  query  and  report  facilities  include  the  ability  to  perform 
functions  from  a  host  language,  relational  and  Boolean  operators,  and 
built-in  summary  functions  (for  counts,  averages,  minima,  and  so  on).  The 
relational  calculus  used  in  ORACLE'S  query  language  allows  multiple  record 
types  to  be  retrieved  in  a  query  (a  relational  join). 

All  standard  restart  and  recovery  features  are  provided,  including  an 
audit  log,  the  ability  to  dump  or  copy  entire  data  base  files,  and 
checkpointing  with  rollback  and  rollforward. 

Security  provisions  for  ORACLE  were  rated  as  satisfactory,  having  the 
ability  to  protect  files  against  unauthorized  access,  and  to  authorize 
read-only  or  write  permission.  The  data  base  administrator  can  authorize 
other  users  to  set  permissions. 

Concurrency  controls  also  include  all  standard  features,  supporting  shared 
access  to  data  files,  multi-user  access,  and  multi- threaded  access.  Data 
definition  capabilities  are  similar  to  those  of  the  other  systems  under 
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test,  including  both  schema  and  subschema  definition  facilities.  New  table 
columns  and  indexes  can  be  added  dynamically.  The  data  base  can  be 
reorganized  automatically  for  greater  retrieval  efficiency  or  better 
storage  utilization.  Multi-volume  files  are  not  supported. 

Memory  requirements  for  ORACLE  are  80K  words,  making  it  the  largest  of  the 
three  systems  under  test.  It  is  also  the  most  expensive,  with  a  cost  (at 
the  time  of  testing)  estimated  at  about  $48,000,  some  $10,000  more  than 
ADABAS-M  and  $34,000  more  than  SEED.  Cost  was  not  heavily  weighted  in 
Mc2*s  evaluation. 

Documentation  was  comparable  to  that  of  the  other  systems  tested, 
including  user  manual,  operator  manual,  programming  manual,  and  training 
materials.  Although  training  was  provided  on-site,  the  vendor  has 
discontinued  on-site  training  in  favor  of  training  at  the  vendor's 
offices.  ORACLE  training  was  the  least  well-organized,  with  informed 
presentations  of  a  series  of  vlewgraphs  by  one  of  the  vendor's 
representatives.  The  instructor  depended  heavily  on  questions  from  the 
participants.  However,  ORACLE  is  probably  the  easiest  of  the  three  systems 
to  learn  independently,  without  formal  training  sessions. 

ORACLE  is  rated  as  fairly  portable.  It  is  written  in  the  C  programming 
language  and  is  available  in  versions  for  IBM  and  DEC  computer  equipment. 

Altogether,  in  Mc^'s  initial  evaluation,  ORACLE  scored  nearly  as  well  as 
ADABAS-M,  and  better  than  any  other  system  considered.  Its  positive 
features  were  seen  as  its  effective  facilities  for  data  definition,  based 
on  its  relational  data  model,  and  its  query/report  functions.  Negative 
factors  included  restrictions  on  the  size  of  the  data  base,  and  its  large 
memory  requirement.  The  high  cost  may  also  be  a  negative  factor  in  some 
applications. 


10.3  SEEP  Charas.t$rlatlcg 


SEED  is  quite  different  in  concept  from  ADABAS-M  and  ORACLE,  emphasizing 
efficiency  in  data  storage  and  retrieval,  rather  than  flexibility  and  ease 
of  use.  Based  on  CODASYL  recommendations,  SEED  uses  a  hierarchical  network 
to  represent  data  structures.  The  user  must  be  aware  of  this  network 
structure  in  order  to  use  SEED  effectively.  In  some  environments, 
particularly  those  in  which  the  same  types  of  queries  are  frequently  used, 
SEED'S  greater  efficiency  in  retrieval  will  be  an  advantage.  Literature 
from  the  vendor  indicates  that  a  user  interface,  which  will  permit  the 
user  to  specify  data  in  relational  forms,  has  been  made  available.  Since 
the  difficulty  in  writing  SEED  schema  definitions  was  one  of  the  major 
problems  in  testing  and  evaluating  the  system,  use  of  the  relational  user 
interface  could  make  SEED  a  more  effective  DBMS. 

Like  the  other  two  systems,  SEED  provides  a  full  range  of  update/load 
facilities,  including  the  ability  to  modify  and  edit  individual  data 
items,  and  to  add  or  delete  records.  A  bulk  load  facility  is  provided. 
Relational  and  Boolean  operators  may  be  used  to  qualify  record 
specifications  for  modification  or  deletion.  Update  and  load  functions  may 
be  performed  from  application  programs. 

SEED  has  a  full  range  of  query  and  report  components,  including  the 
ability  to  perform  query  and  report  functions  from  a  programming  language. 
Unlike  other  network-oriented  systems,  SEED  permits  the  use  of  relational 
and  Boolean  operators  to  qualify  records  or  data  items  for  retrieval. 

Restart  and  recovery  components  are  provided,  including  an  audit  log,  the 
ability  to  dump  or  copy  data  base  contents,  and  a  checkpoint  facility, 
with  rollback  and  rollforward  capabilities.  Facilities  for  data  security 
are  provided. 


10-6 


Concurrency  controls  permit  multiple  users  to  access  the  same  collection 
of  data  at  a  lower  level  than  the  entire  data  base,  e.g.  file,  set,  or 
relation.  Data  definition  components  include  the  ability  to  define  schemas 
and  subschemas.  SEED  also  supports  facilities  for  reorganization  of  the 
data  base  for  greater  storage  and  retrieval  efficiency. 

SEED  includes  a  monitoring  facility  to  determine  and  report  on  the  status 
of  the  SEED  files,  such  as  the  number  of  records,  percent  filled,  etc. 
SEED  will  support  large  data  bases  (one  billion  bytes  or  larger)  and 
multi-volume  files.  Memory  requirements  are  approximately  50K  words.  SEED 
has  the  lowest  cost  among  the  three  systems  tested,  estimated  at  $14,000 
at  the  time  of  evaluation. 

Complete  documentation  for  SEED  was  provided,  including  a  user  manual, 
programming  manual,  and  training  materials.  Training  was  provided  on-site. 
The  vendor  has  developed  a  particularly  effective  course  of  training,  with 
a  variety  of  approaches  and  many  carefully-planned  student  exercises. 
However,  many  of  the  examples  used  in  training  were  too  simple  to  provide 
guidance  for  later  use  of  the  system,  and  the  level  of  training  provided 
seemed  to  be  inconsistent. 

SEED  is  implemented  in  Fortran,  with  IBM,  Modcomp,  CDC,  T0PS-10,  and  VAX 
versions  available.  The  version  used  for  testing  was  modified  by  the 
vendor  for  the  IAS  operating  system  for  the  PDP-11/70.  Some  problems  in 
system  performance  may  be  traced  to  the  need  for  using  this  modified 
system,  rather  than  one  which  was  specifically  developed  for  IAS. 

In  the  initial  evaluation,  SEED  rated  nearly  as  high  as  ADABAS-M  and 
ORACLE,  and  higher  than  most  of  the  other  systems  considered.  It  was  rated 
highly  for  its  low  cost  and  portability.  For  applications  in  which  these 
factors  are  important,  SEED  would  have  an  even  higher  rating.  It  was 
regarded  as  less  Impressive  in  its  update,  load,  query,  and  report 
functions,  and  in  its  security  and  concurrency  facilities. 


11.0  USE  OF  SYSTEM 


This  section  describes  the  procedures  that  were  followed  in  setting  up  and 
running  the  Benchmark  Driver.  In  addition  to  outlining  the  design  of  the 
RTE  approach,  it  will  provide  guidance  for  future  users  of  the  system. 

In  order  to  execute  a  test  run,  a  series  of  steps  in  precise  order  must  be 
performed.  These  steps  ensure  that  the  system  is  configured  correctly  and 
that  all  of  the  tools  to  capture  the  resulting  statistics  for  evaluation 
are  operative.  A  checklist  was  developed  and  followed  to  ensure  that  the 
steps  were  accomplished  in  their  proper  order. 

Step  1:  Position  the  data  base  to  its  ground  zero  position:  At  the 
beginning  of  each  test  run,  the  contents  of  the  data  base  must  be  restored 
to  the  same  initial  values.  This  will  ensure  that  any  variations  in 
results  are  due  to  the  load  imposed  upon  the  DBMS  from  the  scenarios  and 
not  to  any  difference  in  data  base  contents.  ADABAS-M  had  to  be  shut  down 
before  any  of  the  files  could  be  restored.  Indirect  command  files  were 
constructed  containing  the  series  of  commands  to  restore  the  proper  files, 
named  REST0REX.CMD  in  UFD  [7,7] .  To  execute  these  files,  "RESTOREX"  is 
typed,  where  X  is  the  number  of  the  scenario  that  is  being  tested.  All 
files  used  by  that  scenario  were  restored.  Similar  command  files  were 
constructed  for  ORACLE  to  simplify  the  restoration  process. 

Step  2:  Bring  up  the  DBMS:  Since  ADABAS-M  had  to  be  shut  down  before  any 
of  the  files  could  be  restored  to  their  baseline  position,  ADABAS-M  had  to 
be  activated  and  all  files  used  by  the  scenarios  under  test  had  to  be 
opened  before  any  test  could  be  initiated.  In  ORACLE,  it  was  not 
necessary  to  shut  down  the  system  in  order  to  restore  the  data  base;  hence 
this  step  does  not  apply  to  ORACLE  runs. 
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Step  3:  Restoration  of  the  Seed  files:  The  Seed  file  contained  the  seeds 
used  for  the  random  number  generator  called  by  the  scenarios.  The 
Benchmark  Driver  would  access  the  seed  file  and  select  the  next  unused 
seed  in  the  file  each  time  a  random  number  generator  needed  to  be  seeded 
during  execution  of  the  scenarios.  As  each  seed  was  selected  from  the 
file,  it  was  marked  by  the  BMD  so  that  the  same  seed  was  not  reused  in 
that  specific  test  run.  These  flags,  marking  the  used  seeds,  had  to  be 
cleared  before  each  test  run,  and  the  order  of  the  seeds  had  to  be  set  to 
ensure  that  each  test  run  could  be  duplicated  exactly  in  each  DBMS  under 
test.  A  short  program  was  written  to  allow  the  user  to  set  the  seed  file 
with  the  sequence  of  seeds  to  be  used. 

Step  4:  Set  up  the  General  Purpose  Monitor  input  parameters:  Files 
containing  the  input  parameters  for  all  of  the  different  options  in  the 
GPM  for  the  different  scenarios  were  built  and  stored.  For  the  specific 
scenarios  under  test,  the  appropriate  files  were  recalled  and  used  as 
input  for  the  GPM. 

Step  5:  Install  the  proper  number  of  tasks  for  each  scenario  for 
ADABAS-M:  The  ADABAS-M  IT  pseudo-device  handler  cannot  handle  multiple 
occurrences  of  the  same  task  name.  In  RSX-11,  under  which  the  IT  driver 
was  developed,  duplicate  names  are  not  allowed.  This  is  not  so  in  IAS. 
Duplicate  task  names  may  exist;  tasks  are  differentiated  by  their  Job 
Number.  If  multiple  copies  of  the  Collection  Coordination  scenario  with 
the  same  name  exist,  the  packet  of  information  will  go  to  the  first 
Collection  Coordination  scenario  task,  which  may  not  be  the  correct  copy. 
For  the  RTE,  the  BMD  was  designed  and  coded  for  multiple  copies  of  each 
scenario.  Therefore,  each  task  or  copy  of  a  scenario  will  have  to  be 
installed  under  a  unique  name,  limiting  the  number  of  copies  which  may 
exist  at  any  one  time. 


Step  6:  Se:  up  the  Benchmark  Driver:  The  Benchmark  Driver  (BMD)  is  the 
program  that  will  begin  a  testbed  session.  The  user  will  run  this  program 
to  set  scenario  and  script  parameters,  then  execute  a  session.  To  execute 
the  Benchmark  Driver,  BMD  is  entered  at  the  terminal.  The  BMD  program 
will  respond  with  the  prompt: 

BMD> 

requesting  the  user  to  enter  the  desired  parameter.  The  possible 
commmands  or  parameters  are: 

SC  Set  control  file  parameters 

SA  Save  the  display 

ED  Edit  the  current  display 

PR  Print  the  display  on  the  line  printer 
RU  Execute  the  Benchmark  test  run. 

The  sequence  of  commands  to  execute  a  typical  evaluation  run  is  as 
follows: 

a)  Execute  the  SC  command  to  review  the  parameters  saved  in  the  file  from 
a  previous  test  run.  By  the  saving  the  parameter  files,  the  run  could  be 
duplicated  exactly  at  a  later  time  if  desired.  If  modifications  of  the 
parameters  in  the  stored  file  were  desired  the  user  would  proceed  to  Step 
b.  Otherwise,  the  user  would  proceed  to  Step  e. 

b)  Execute  the  ED  command  to  edit  the  current  parameters. 

c)  Execute  the  SA  command  to  save  the  current  parameters. 
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d)  Execute  the  PR  command  to  print  the  parameters  at  the  line  printer. 
When  the  output  of  the  GPM  was  printed  at  the  completion  of  the  test  run, 
a  complete  hardcopy  record  was  thus  produced. 

e)  The  Run  command  is  not  invoked  until  the  GPM  has  been  initiated. 

Step  7:  Start  the  GPM. 

Step  8:  Start  the  actual  execution  of  the  scenarios  by  executing  the  Run 
command  of  the  BMD. 

Step  9:  Stop  the  GPM:  At  the  completion  of  the  test,  stop  the  GPM, 
format  the  raw  statistics  file  for  printing,  print  the  statistics  for  the 
test  run  on  the  line  printer. 
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12.0  BENCHMARK  TEST  METHODOLOGY 


RTE  testing  was  first  introduced  during  the  late  1960s  in  the  form  of  a 
sophisticated  system  driver  to  simulate  multiple  interactive  users  in  a 
time-shared  computer  system.  The  RTE  software  emulates  (i.e.  attempts  to 
reproduce)  the  behavior  of  terminal  users  as  they  send  commands  to  the 
System  Under  Test  (SUT)  and  receive  responses  from  the  SUT. 

By  emulating  the  behavior  of  the  terminal  users,  the  RTE  approach  permits 
an  inexpensive,  controlled,  repeatable  series  of  system  tests.  It 
contrasts  with  live  testing,  which  is  expensive  (in  terms  of  personnel  and 
equipment  times),  uncontrolled  (human  actions  cannot  be  completely 
controlled),  and  unrepeatable  (human  behavior  is  not  precisely 
repeatable) . 

An  RTE  is  capable  of  loading  the  system  with  a  large  number  of  simulated 
user  terminals,  which  operate  at  a  controlled  rate,  to  permit  testing  of 
relevant  system  characteristics,  such  as  response  times,  resource 
requirements,  and  behavior  under  overload.  The  RTE  tests  the  ability  of 
the  DBMS  to  respond  to  the  needs  of  I&W  analysts  accessing  the  data  base 
through  their  terminals. 

Some  typical  analyst  tasks  may  be  listed  as  follows: 
o  Review  messages 

o  Consult  with  other  sources 

o  Issue  an  alert 

o  Flag  an  item  for  further  investigation 


o 


Route  messages 


o  Access  data  bases 

o  Correlate  data  about  this  situation 

o  Analyze  this  situation,  i.e.  determine  its  meaning,  relevance, 
or  implications 

o  Project  near-term  estimates  of  intensity,  scope,  and  direction 
of  threat 

The  purpose  of  the  RTE  benchmark  tests  is  to  provide  statistical 
information  concerning  operation  of  each  of  the  systems  in  the  performance 
of  these  tasks  to  permit  the  identification  of  significant  differences 
among  the  systems. 

Proper  procedures  for  a  benchmark  test  require  that  testing  conditions  for 
each  of  the  systems  will  be  the  same.  Several  factors  made  this 
experimental  design  unworkable.  Specifically,  errors  in  software  supplied 
for  all  three  systems,  particularly  those  errors  that  led  to  the 
withdrawal  of  ADABAS-M  from  the  market,  together  with  the  intractability 
of  the  SEED  schema  definitions,  seriously  curtailed  the  benchmark 
evaluation  process.  Although  the  evaluation  might  have  stopped  at  this 
point,  it  was  felt  that  a  portion  of  the  RTE  should  be  completed.  In  this 
way,  the  test  facility  could  be  demonstrated  and  valuable  information 
could  be  obtained  concerning  DBMS  characteristics.  The  only  major 
limitation  would  be  that  a  full  statistical  analysis  of  differences  among 
the  systems  would  have  to  be  omitted. 

The  RTE  Benchmark  Driver  initiates  scripts,  submitting  them  to  the  DBMS 
under  test.  While  executing,  the  scripts  provide  output  resembling  that  of 
an  analyst  at  a  terminal,  which  is  submitted  to  the  system  under  test. 
Operation  of  the  BMD  is  monitored  by  the  General  Purpose  Monitor,  which 
provides  statistical  information  concerning  system  performance. 


The  Benchmark  Driver  is  under  the  control  of  the  user,  who  submits 
commands  to  it  for  execution.  The  following  paragraphs  briefly  describe 
each  of  the  user  commands.  In  all  cases,  brackets  []  enclose  optional 
fields  and  parentheses  ()  enclose  alternate  names. 

SET-C.ONTROLS(  SCI  =  f  filename  1 

This  command  retrieves  a  set  of  control  parameters  using  the  given  or  the 
default  filename  together  with  suffix  n.CPn  (if  no  suffix  is  supplied, 
".CP"  is  assumed).  The  control  parameters  from  this  file  are  displayed. 
The  default  filename  is  set  to  the  given  filename,  if  present.  Subsequent 
file  accesses  will  be  prefixed  with  this  default  filename  until  another  SC 
command  is  executed.  (EXAMPLE:  SC  =  EXEROO). 

S-ITEMS  (SI)  =  T filename . 1 F suff 1x1 

This  command  will  cause  the  retrieval  and  display  of  the  S-Item  parameter 
set  contained  in  the  file  with  a  name  equal  to  the  given  (or  default) 
filename  together  with  the  given  suffix.  The  suffix  to  be  used  to 
represent  one  of  the  six  scripts  must  be  SI,  S2,  S3,  S4,  S5»  or  S6.  For 
example,  S-Items  previously  SAVEd  for  script  one  could  be  recalled  using 
the  default  filename  by  using  the  command:  S-ITEMS=S1 .  If  more  than  one 
parameter  set  has  been  saved  under  this  filename,  the  system  returns  the 
first  set  found. 


5AVE.-I  filename , ,]  f  suffix  1 

The  SAVE  command  stores  the  values  from  the  currently  displayed  menu  into 
a  file  with  a  name  equal  to  the  given  (or  default)  filename  together  with 
the  gi  »n  suffix  or  the  default  suffix  (for  the  data  currently  being 
displayed).  (EXAMPLE:  SAVE=EXER01 ) .  To  avoid  later  confusion,  care  should 
be  taken  that  f ilename: suffix  pairs  are  unique. 
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PRINTS  £  file  name . 1 r suffix! 


This  command  results  in  a  hardcopy  being  printed  of  the  contents  of  the 
given  (or  default)  filename  using  the  given  or  default  suffix  (for  data 
currently  being  displayed).  (EXAMPLE:  PRINT=S2FILE,S2) . 

STATS=filename 

This  command  causes  the  hardcopy  production  of  formatted  statistical 
reports  using  the  statistics  data  stored  in  "filename".  (EXAMPLE: 
STATS=STAT01). 

RUN= r filename 1 

This  command  causes  the  start  of  a  Benchmark  Exercise  by  using  the  given 
(or  default)  filename  together  with  suffix  ".CP"  to  access  the  file  of 
control  parameters  to  use  for  the  exercise.  Based  upon  the  setting  of  the 
control  parameter  FLAG  fields,  the  "S-Item-FILE"  filename  will  be  used 
with  the  appropriate  suffix  for  each  of  the  "active"  scripts  to  access  the 
set  of  S- Items  for  each  script.  (EXAMPLE:  RUN=EXER01). 

EALX 

This  command  causes  the  current  Benchmark  Exercise  to  cease  execution 
temporarily. 

RESUME 

This  command  allows  a  previously  HALTed  Benchmark  Exercise  to  be 

restarted. 

STOP 

This  command  causes  the  Benchmark  Exercise  to  be  terminated  and  statistics 
to  be  computed  and  stored. 


This  section  presents  detailed  results  of  the  Benchmark  Tests  performed 
during  this  project.  In  general,  execution  of  benchmark  tests  was 
monitored  by  the  General  Purpose  Monitor  to  provide  comparative  statistics 
concerning  DBMS  performance. 

Several  developments  have  affected  the  format  in  which  results  are 
presented: 

o  As  noted  elsewhere  in  this  report,  problems  with  the 
implementation  of  ADABAS-M  have  caused  the  vendor  to  withdraw  the  system 
from  further  sale. 

o  ORACLE  2.3,  used  for  the  tests,  has  been  superseded  by  ORACLE 
3.0,  which  is  said  to  have  greatly  improved  performance  characteristics. 

o  Problems  in  preparing  schema  definitions  for  SEED  curtailed  the 
full  development  of  a  data  base  for  this  system.  As  a  result,  only  a  very 
limited  number  of  tests  of  this  DBMS  were  possible. 

The  impact  of  these  restrictions  on  the  test  design  has  been  to  place 
greater  emphasis  on  human  factors  and  other  characteristics  which  cannot 
be  directly  measured,  such  as  quality  of  documentation.  An  evaluation  of 
these  factors  is  needed  to  meet  the  complaints  and  requirements  originally 
stated  by  I&W  analysts.  A  major  contribution  of  the  evaluation  project 
may  well  be  the  discovery  of  the  severe  limitations  of  the  hardware  and 
software  that  are  available  for  support  of  I&W  analysis. 

With  these  caveats,  the  results  of  the  benchmark  tests  are  presented  in 
this  section. 


Six  of  the  scenarios  described  in  Section  3«0,  representing  various  types 
of  analyst  activities,  based  upon  the  following  six  intelligence  tasks, 
were  defined  in  DHIL  and  translated  into  scripts: 

o  Watch 

o  I&W  Analysis 

o  Collection  Coordination 

o  Area  Analysis 

o  Military  Systems  Analysis 

o  MAC  Route  Assessment 

To  simulate  variations  in  the  performance  of  the  tasks,  pseudo-random 
variations  are  introduced  into  the  scripts.  The  same  set  of  pseudo-random 
variations  is  used  for  each  of  the  systems  under  test,  to  permit  direct 
comparisons  among  the  systems.  In  addition: 

o  Varied  levels  of  alert  (peace,  crisis,  war)  are  simulated. 

o  Varied  loads  are  introduced,  including  variations  in  the  number 

of  terminals  and  in  the  number  of  scripts  processed  at  each 
terminal . 

A  universal  top-level  software  translator  was  designed  to  translate  the 
DHIL  scenarios  into  Fortran  code  with  embedded  DBMS-specific  calls.  The 
design  of  the  translator  was  not  implemented  in  code  because  of  the 
complexity  of  the  task,  given  the  requirement  to  be  absolutely  fair  to 
each  of  the  DBMSs  under  evaluation.  Instead,  scenarios  were  hand- 
translated  into  executable  code.  A  given  set  of  procedures,  developed 


during  the  translator  design  process,  were  followed  by  the  implementor  for 
each  scenario  translation.  These  procedures  were  the  same  for  each  DBMS. 
Only  details  of  implementation  were  different. 

For  ADABAS-M  the  files  which  must  be  opened  for  each  scenario  are  included 
in  Table  13-1.  ADABAS-M  limits  the  number  of  files  that  can  be  open  at  the 
same  time.  As  the  Watch  scenario  was  originally  defined,  it  required  18 
files  to  be  opened.  Some  initial  tests  of  the  RTE  exceeded  the  upper  limit 
for  ADABAS-M,  when  an  attempt  was  made  to  run  the  Collection  Coordination 

and  Watch  scenarios  concurrently.  Because  of  the  importance  of  running 

multiple  scenarios,  some  calls  to  the  data  base  were  eliminated  from  each 
scenario.  Version  2  of  the  Watch  scenario  uses  only  14  files,  to  allow 
room  for  storage  of  files  required  by  ether  scenarios.  Files  A001B,  A001C, 
A001D,  and  A001E  were  eliminated.  Identical  modifications  were  made  for 
each  DBMS. 

In  addition,  files  C001B  and  C001C  were  eliminated  from  the  demonstration 
version  of  the  system,  to  permit  the  WEIS  file  to  be  opened  at  the  same 

time.  In  the  demonstration,  WEIS  was  used  on  an  interactive  basis,  using 

cartographic  displays,  with  the  RTE  operating  in  the  background,  to 
illustrate  the  effect  of  multiple  tasks  competing  for  system  resources. 

Three  versions  of  the  Watch  Function  scenario  were  fully  implemented: 

o  Version  1,  used  when  no  other  scenarios  were  in  use,  operated 
with  18  files. 

o  Version  2,  used  when  other  scenarios  required  data  storage 
areas,  operated  with  14  files. 

o  Version  3,  used  during  demonstrations  of  the  system,  operated 
with  13  files,  to  permit  use  of  the  WEIS  data. 
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File  Mane 


Messages 

A001A, 

Events 

B001A, 

Order  of  Battle 

C001A, 

Personalities 

D002F 

Country  Summary 

E001A 

Indicator  Lists 

F001A 

Friendly  Mission  Data 

H001A 

Air  Route  Segments 

I002A 

A001B,  A001C,  A001D,  A001E,  A1 TEXT 
B001B 

C001B,  C001C,  COO ID 

F001B 


Table  13-1  Files  Used  by  Watch  Function  Scenario 
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The  files  required  for  operation  of  the  system  for  Version  1  are  shown  in 
Table  13-1.  The  Task  Information  Blocks  (TIBs)  are  described  in  more 
detail  in  Appendix  D. 

The  Collection  Coordination  scenario  was  the  first  to  be  completely 
implemented,  because  it  required  the  smallest  number  of  files.  Two 
versions  were  implemented  under  ADABAS-M.  Version  1  would  update  the 
G-file  (Collection  Request  Form)  after  processing,  while  Version  2  would 
update  and  delete  the  collection  request  after  processing  the  request. 
Both  versions  were  executing  under  ADABAS-M  and  could  run  in  conjunction 
with  the  Watch  scenario.  These  modifications  to  the  scenarios  were 
applied  to  tests  for  all  three  DBMSs,  thus  presenting  equal  loads  and 
variations  of  activity.  Section  13.2  presents  suggested  enhancements  to 
the  DBMSs  which,  if  implemented,  would  make  the  modifications  to  the 
scenarios  unnecessary. 

A  special  Update  scenario  was  developed  to  add  records  or  requests  to  the 
G-file.  This  scenario  simulates  the  process  by  which  analysts  add 
collection  requests  for  the  Collection  Coordination  analyst  to  process. 
Each  time  this  scenario  was  executed,  it  would  add  50  collection  requests 
to  the  file. 

All  modules  of  the  Area  Analysis  scenario  were  designed,  coded  and  tested 
successfully,  using  a  small  subset  of  the  files  developed  specifically  for 
testing.  Because  of  the  number  and  size  of  the  modules,  this  scenario 
could  not  be  successfully  taskbuilt,  since  the  size  of  the  object  code 
exceeded  the  maximum  size  allowed  per  program.  A  solution  to  this  problem 
was  to  break  up  the  modules  even  further,  and  to  implement  an  overlay 
structure.  The  initial  design,  as  implemented  in  code,  would  require 
recoding  and  retesting,  taking  into  account  the  required  overlay 
structure.  The  modules,  as  delivered,  have  all  been  tested  successsfully 
and  are  executing  correctly,  but  the  overlay  structure  has  not  been 
implemented  at  this  time,  and  the  scenario  has  not  been  used  in  the  RTE. 
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The  modules  Included  in  the  I&W  Analysis  scenario  have  all  been  coded  and 
partially  tested.  Due  to  the  errors  in  ADABAS-M  and  its  loader,  the  16 
files  required  to  complete,  test,  and  execute  this  scenario  were  not  all 
loaded  within  the  time  limits  of  this  project,  and  no  further  testing  of 
this  scenario  took  place. 

Individual  modules  of  the  MAC  Route  Assessment  and  Military  Systems 
Analysis  scenarios  were  coded.  Difficulties  with  the  ADABAS-M  loader  led 
to  suspension  of  further  tests  of  these  scenarios. 

Table  13-2  shows  the  implementation  status  of  each  of  the  scenarios  for 
ADABAS-M. 

Translation  of  the  scenarios  into  FORTRAN  programs  for  use  with  SEED  was 
not  completed  because  of  the  difficulty  and  time  required  to  define 
schemas  for  this  purpose.  The  following  steps  were  carried  out  in  order  to 
define  SEED  schemas  and  to  select  a  scenario  for  implementation.  The 
general  approach  to  schema  definition  for  SEED  consisted  of  two  parts: 

o  A  first-level  design  using  a  basic  schema  design  diagram.  The 
vendor  evaluated  the  first-level  design  of  a  representative  TIB,  with 
comments  and  recommendations  to  be  incorporated  into  implementations  of 
the  remaining  TIBs. 

o  Entering  and  compiling  schemas,  and  making  adjustments  to  meet 
system  limitations. 

The  complexity  of  a  SEED  schema  is  a  function  of  the  number  of  keys,  the 
number  of  repeating  groups,  and  the  number  of  items  found  in  the  file. 
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Sfigaacla  Nana 

Watch 

Version 

Version 

Version 

Collection  Coord. 

Version 

Version 

Status 

1  (18  files):  implemented 

2  (14  files):  implemented 

3  (demo,  13  files):  implemented 

1 :  implemented 
2:  implemented 


Area  Analysis  Modules  tested  individually  and  running 

Overlays  necessary  for  implementation 


MAC  Route  Assessment 

I AW  Analysis 
Military  Systems 
Update  Message  File 

Modified  Update 


Coded  but  not  completely  tested 
Coded  but  not  completely  tested 
Coded  but  not  completely  tested 

Coded 

Implemented 


Table  13-2  Implementation  Status  of  Scenarios  for  ADABAS-M 
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Table  13-3  indicates  the  complexity  level  of  TIB  implementation  for  the 
scenarios.  In  addition,  the  number  of  items  is  indicated.  If  the  number  of 
items  is  less  than  50,  it  is  coded  small  (S);  between  50  and  99,  medium 
(M);  between  100  and  200,  large  (L);  and  greater  than  200,  very  large 
(VL). 

A  first-level  design  layout  of  TIB  E002,  Installation  Information,  which 
did  not  take  into  account  any  system  limitations,  was  completed  after 
consultations  with  the  vendor.  E002  was  selected  for  the  following 
reasons: 

o  It  is  one  of  the  largest  and  most  complex  of  the  TIBs. 

o  It  is  indicative  of  all  of  the  the  problems  or  features  to  be 
found  in  the  rest  of  the  TIBs. 

o  It  has  a  large  number  of  keys  and  repeating  groups. 

The  initial  design  was  forwarded  to  the  vendor  for  evaluation  and  comment. 
No  faults  were  found  in  the  design. 

In  order  to  perform  a  fair,  unbiased  evaluation  of  the  three  DBMSs,  the 
same  number  of  total  hours,  160,  was  allocated  to  the  schema  definition 
task  for  each  DBMS  under  evaluation.  Since  it  was  apparent  that  SEED  would 
require  considerably  more  than  this  allocation,  the  complexity  estimates 
were  used  to  assist  in  determining  how  best  to  distribute  resources  for 
the  schema  definition  task.  Table  13-4  indicates  the  TIBs  used  by  each 
scenario.  The  complexity  factor  is  enclosed  in  parentheses. 

Since  the  Collection  Coordination  scenario  uses  the  smallest  number  of 
TIBs,  it  was  completed  first  for  all  three  systems.  In  this  way 
preliminary  performance  statistics  used  for  system  checkout  and  for 
comparisons  were  obtained  before  all  of  the  scenarios  were  translated  and 


WATCH 

AREA 

I&W 

MAC  ROUTE 

COLLECTION 

MIL-SYS. 

TIB 

FUNCTION 

ANAL 

ANAL 

ASSESSMENT 

COORDINATION 

ANAL . 

A001 

XXX (2) 

XXX ( 2 ) 

XXX ( 2 ) 

. 

XXX( 2 ) 

B001 

XXX ( 5) 

. 

XXX( 5) 

XXX( 5) 

♦ 

« 

COOL 

XXX (5) 

XXX (5) 

XXX ( 5 ) 

XXX ( 5 ) 

• 

D001 

• 

XXX (A) 

XXX(A) 

XXX (A) 

* 

XXX  ( A ) 

D002 

XXX ( 7 ) 

• 

. 

. 

• 

• 

>:ooi 

XXX ( 3 } 

• 

. 

XXX (3) 

• 

• 

F001 

XXX ( I) 

XXX(l) 

XXX(l) 

XXX(l) 

« 

• 

G00I 

• 

XXX(  3 ) 

• 

. 

XXX ( 5 ) 

XXX(5) 

11001 

XXX (3) 

XXX ( 3 ) 

XXX ( 3  ) 

XXX ( 3 ) 

XXX  ( 3 ) 

XXX( 3 ) 

J.O01 

XXX ( 2 ) 

• 

. 

XXX (2) 

. 

• 

1002 

XXX( 5) 

XXX (3) 

XXX ( 5) 

XXX( j) 

. 

XXX(3) 

J001 

* 

• 

• 

• 

XXX(l) 

• 

TOTAL 

TIBS 

■  ’  SKI) 

9 

7 

7 

7 

3 

6 

Note:  "XXX"  indicates  that  the  TIB  is  used  for  the  given  scenario. 

Complexity  estimates  are  given  in  parenthesis. 


Table  1 3  —4  TIBs  Per  Scenario 


all  TIBs  loaded.  SEED  schema  definitions  proved  to  require  a  great  deal  of 
time,  and  the  choice  of  other  scenarios  for  SEED  tests  was  critical.  While 
the  Military  Systems  Analysis  scenario  uses  only  six  TIBs,  one  of  these  is 
TIB  E002,  one  of  the  most  difficult  TIBs  to  implement.  With  the  allocation 
of  time  for  SEED  schema  definitions  more  than  exhausted,  it  was  necessary 
to  proceed  with  an  evaluation  based  on  a  limited  set  of  input  queries. 

The  following  evaluation  criteria,  extracted  from  the  SOW  (4.3.2)  were 
applicable  to  tests  of  SEED,  using  a  limited  set  of  queries: 

o  Data  Base  Creation 

o  Data  Base  Update 

o  Storage  and  Retrieval  of  Data 

o  Response  to  Analyst  Queries 

o  Ease  of  Use 

o  Overall  Performance 

It  was  apparent  that  these  key  DBMS  evaluation  criteria  could  be  observed 
and  measured  for  SEED.  DBMS  performance  could  be  monitored  by  the  General 
Purpose  Monitor  (GPM)  to  obtain  the  technical  factors,  such  as  disk 
activity,  accesses  per  query,  and  CPU  overhead.  Behavior  of  the  system 
under  saturation  and  overload  conditions  could  be  determined  by  using  a 
number  of  replications  of  the  same  scenario,  rather  than  a  mixture  of  all 
scenarios,  a3  orginally  planned.  Such  factors  as  the  ease  with  which 
commands  can  be  written,  their  readability,  and  many  specific  problems 
encountered  in  the  use  of  the  language  are  independent  of  the  number  of 
scenarios  translated.  Quantitative  measures,  such  as  labor  hours  required 
for  design  and  machine  time  required  to  load  the  data  base  could  be  made. 


13-7 


Difficulties  in  writing  schema  definitions  in  the  SEED  language  or 
problems  encountered  in  loading  could  be  noted  and  documented.  For  these 
reasons,  an  evaluation  of  SEED  could  still  be  completed,  even  though  only 
one  scenario  was  translated  and  implemented. 

Errors  in  SEED  appear  to  be  due  to  the  need  to  use  the  system  under  the 
IAS  operating  system,  which  required  software  modifications  performed  by 
the  vendor. 

For  ORACLE,  all  of  the  modules  for  each  scenario  have  been  coded.  All  were 
successfully  tested  individually  before  integration.  Although  programs  for 
ORACLE  were  simpler  to  write,  they  tended  to  be  much  longer  than  those  for 
ADABAS  and  SEED.  The  voluminous  code  associated  with  ORACLE  DBMS  calls 
forced  most  of  the  scenarios  into  an  overlay  structure.  Table  13-5  shows 
the  implementation  status  of  each  of  the  scenarios  for  ORACLE. 

Table  13-6  describes  each  Test  Series  executed  during  the  RTE  Benchmark. 
The  top  half  of  the  table  for  each  Test  Series  shows  the  scenario(s)  that 
were  performed.  The  bottom  half  shows  the  activity  generated  against 
files  of  the  data  base. 

Table  13-7  is  organized  by  selected  measurements  indicating  relative  DBMS 
performance  for  each  measurement. 

A  full  presentation  of  all  results,  by  test,  is  contained  in  Table  13-8. 


Watch 

Collection  Coord. 
Area  Analysis 
MAC  Route  Assess. 
I&W  Analysis 
Military  Sys.  Anal. 
Modified  Update 


Coded;  overlays  required 
Two  versions  implemented 
Coded;  overlays  required 
Coded;  overlays  required 
Coded;  overlays  required 
Coded;  overlays  required 
Implemented 


Table  13-5  Scenarios  for  ORACLE 
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I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  A 


Scenario 


No. 


Collection  Coordination 
Update  Only  (Seed  10) 


Files 

No.  , 

! 

1  No. 

1  Modifies 

Affected 

Searches 

Rees 

Adds 

L_K££±J 

Terminals 

1 


No. 

Rees  Deletes 


I&W  DBMS  ANALYSIS 

TEST  DESCRIPTION 

Test  ID:  B 

Scenario 

No.  Terminals 

Collection  Coordination 

1 

Update  Only  (Seed  20) 

Files  i  1  No .  1  1  No. 

1  No.  1  I  No.  |  No.  Rec 

Affected  Searches  Rees  Adds  Rees  Modifies  Rees  Deletes  Rees  Loaded 

Table  13-6  T 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  C 


Scenario 

No.  Terminals 

Add  50  Records  to 

1 

G-File  (Seed  10) 

Files 

No. 

No. 

No. 

1 

No. 

Affected 

Searches 

Rees 

Adds 

Rees 

Modifies 

Rees 

Deletes 

Rees 

No.  Rees 
Loaded 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  D 


Scenario 

No.  Terminals 

Collection  Coordination 
Update  and  Delete  (Seed  10) 

i 

1 

Files 

Affected 

Searches 

No. 

Rees 

Adds 

No. 

Rees 

Modifies 

No. 

Rees 

Deletes 

No. 

Rees 

No.  Rees 
Loaded 

G-File 

2 

30 

0 

0 

H-File 

1 

1 

J-File 

1 

30 

Table  13-6  Test  Series  Summary  Descriptions  (Page  4  of  19) 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  E 


Files 

1  No. 

1 

No. 

No. 

No. 

Affected 

Searches  |  Rees 

Adds] 

Rees 

Modifies 

Rees 

Deletes 

Rees 

No.  Recs| 
Loaded 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  F 


Files 

Affected 

Searches 

No. 

Rees 

Adds 

No. 

Rees 

Modifies 

No. 

Rees 

Deletes 

No. 

Rees 

No.  Rees 
Loaded 

G-File 

6 

21 

3 

4 

H-File 

3 

2 

J-File 

3 

102 

Table  13-6  Test  Series  Summary  Descriptions  (Page  6  of  19) 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  G 


Scenario 

No.  Terminals 

Collection  Coordination 
Update  Only  (Seed  30) 

1 

Collection  Coordination 
Update  and  Delete  (Seed  10) 

1 

Add  to  G-File  (Seed  10) 

1 

3 

Files  No.  No.  No.  No.  No-  Rees 

Affected  Searches  Rees  Adds  Rees  Modifies  Rees  Deletes  Rees  Loaded 


g] 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  H 


Scenario 

No. 

Terminals 

Collection  Coordination 
Update  Only  (Seed  40) 

1 

Collection  Coordination 
Update  and  Delete  (Seed  10) 

1 

Add  to  G-File  (Seed  10) 

1 

3 

Files  No.  No.  No. 

Affected  Searches  Rees  Adds  Rees  Modifies  Rec 


G-File 

H-File 

J-File 


No.  No.  Rees 
Deletes  Rees  Loaded 


-6 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  J 


Scenario 

No.  Terminals 

Collection  Coordination 
Update  Only  (Seed  30) 

3 

Collection  Coordination 
Update  and  Delete  (Seed  10) 

2 

Add  to  G-File  (Seed  10) 

1_ 

I 

6 

Files 

Affected 

Searches 

No. 

Rees 

Adds 

No. 

Rees 

Modifies 

No. 

Rees 

Deletes 

No. 

Rees 

G-File 

10 

93 

50 

50 

4 

13 

2 

7 

H-File 

5 

156 

J-File 

5 

2 

No .  Re 
Loaded 


l, |t.  H-6  Test  Series  Summary  Descriptions  (Page  10  of  19) 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  K 


Scenario 

No.  Terminals 

Collection  Coordination 
Update  Only  (Seed  50) 

3 

Collection  Coordination 
Update  and  Delete  (Seed  10) 

2 

Add  to  G-File 

1_ 

6 

Files 

No. 

No. 

No. 

No. 

Affected 

Searches 

Rees 

Adds 

Rees 

Modifies 

Rees 

Deletes 

Rees 

No.  Rees 
Loaded 


Test  ID:  L 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Scenario 

No.  Terminals 

Collection  Coordination 
Update  Only  (Seed  50) 

5 

Collection  Coordination 
Update  and  Delete  (Seed  10) 

2 

Add  to  G-File 

1 

8 

Files  No.  No.  No.  No.  No.  Rec 

Affected  Searches  Rees  Adds  Rees  Modifies  Rees  Deletes  Rees  Loaded 


G-File 

H-File 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  M 


Scenario 

No.  Terminals 

Watch  with  C-File 

1 

(Seed  10) 

F  iles 

No. 

No. 

1 

No. 

No. 

Affected 

Searches 

Rees 

Adds 

Rees 

Modifies 

Rees  Deletes 

Rees 

No.  Rees 
Loaded 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  N 


Scenario 

No.  Terminals 

Watch  with  C-File 
(Seed  20) 

1 

Files 

No. 

No. 

No. 

No. 

Affected 

Searches 

Rees 

Adds 

Rees 

Modifies 

Rees 

Deletes 

Rees 

No.  Rees 
Loaded 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID:  0 


Scenario 


Watch  without 
C-File  (Seed  10) 


No. 


Files 

Affected 

Searches 

No. 

Rees 

Adds 

No  • 
Rees 

Modifies 

A001A 

1 

1 

0-1 

0-1 

A1TXT 

1 

1 

0-1 

0-1 

B001A 

0-1 

0-420 

B001B 

0-1 

0-420 

C001 A 

0-3 

0-3 

C001D 

0-3 

0-3 

D002F 

0-1 

0-1 

E001A 

1-2 

1-2 

0-1 

F001A 

0-1 

0-400 

F001B 

0-1 

0-400 

H001A 

0-1 

0-11 

1 00  2 A 

0-1 

0-3 

Terminals 


1 


i 

I  No. 

i  Rees  Delet 


0-1 


i 

l 


Table  13-6  Test  Series  Summary  Description  (Page 


I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID: 


Files 

Affected 


Q 


Scenario 

No.  Terminals 

Simple  Query 
(Retrieve  on  one  key) 

0 

No. 

No . 

No. 

No. 

No.  Rees 

Searches 

Rees 

Adds 

Rees 

Modifies 

Rees 

Deletes 

Rees 

Loaded 

I&W  DBMS  ANALYSIS 
TEST  DESCRIPTION 


Test  ID: 


Files 

Affected 


R 


Scenario 

No.  Terminals 

ANDED  Query 
(Retrieve  on  two  keys 
ANDed) 

0 

No. 

No. 

No. 

No. 

Searches 

Rees 

Adds  Rees 

Modifies 

Rees 

Deletes 

Rees 

No.  Rees 
Loaded 


I&W  DBMS  ANALYSIS 
RELATIVE  COMPARISONS 
CPU  ACTIVITY  (SECONDS) 


ADABAS-M 


ORACLE 


I&W  DBMS  ANALYSIS 
RELATIVE  COMPARISONS 

FILE  READ/WRITE  SERVICE  REQUESTS  (RVB,  RLB,  WVB,  WLB) 


TEST  SERIES 


k-: 

A 

B 

C 

1 

,  • 

D 

E 

F 

43 

G 

B 

H 

ADABAS-M 


147 

195 

3,063 

147 

341 

291 

4,228 

4,082 

556 

5,893 

5,917 

ABORTED 


220 

451 

— 

2,235 

— 

235 

— 

745 

— 

803 

— 

3,315 

— 

3,270 

— 

1,086 

— 

5,303 

— 

5,465 

— 

6,839 

— 

3,754 

2,037 

2,678 

4,083/3,922 

46,512 

160,130 

21,637 

56,763 

9,879 

21,497 

4,408 

10,592 

1,874 

2,752 

Table  13-7  Relative  Comparisons  (Page  3  of  6) 


I&W  DBMS  ANALYSIS 
RELATIVE  COMPARISONS 
PHYSICAL  DISK  I/Os 


DBMS 

TEST  SERIES''''^ 

AD ABAS -M 

ORACLE 

SEED 

43b,  029 
164.787 
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I&W  DBMS  ANALYSIS 
TEST  SUMMARY 


IssL  Series:  k 


- - ____DBMS 

ACTIVITY  — - - - 

ADABAS-M 

ORACLE 

ELAPSED  TIME 
( secs) 

426 

1,420 

CPU  -  TOTAL* 

( secs) 

252 

929 

CPU  -  DBMS 
(secs) 

64 

344 

RVB 

3,888 

19 

RLB 

0 

2,637 

WVB 

2,029 

588 

WLB 

0 

2,221 

LOAD  OVERLAY 

4,406 

60 

DJLSK-IQa _ 

10,669 

■Attributable  directly  or  indirectly  to  the  DBMS 
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CPU  -  TOTAL* 
( secs) _ 


CPU  -  DBMS 


CPU  -  TOTAL* 


ELAPSED  TIME 


CPU  -  TOTAL* 


•Attributable  directly  or  indirectly  to  the  DBMS 
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13-8qq 


CPU  -  TOTAL* 


(secs) 


31 


272 


r 


BMS 


I&W  DBMS  ANALYSIS 
TEST  SUMMARY 


ELAPSED  TIME 


TOTAL* 


316 

7,726 

23,181 

152 

5,188 

13,811 

75 

2,380 

3,374 

2,135 

1,867 

71,661 

484 

18,000 

58,190 

1,289 

6,670 

24,486 

332 

19,975 

5,793 

372 

44 

53,917 

7,287 

89,446 

436,029 

■Attributable  directly  or  indirectly  to  the  DBMS 

Table  13-8  I&W  DBMS  Analysis  Test  Summary  (Page  20  of  24) 
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LrLvlvl:  ‘*1- 


*.  *v\ V'.  * >  v  v'' V 

•  **  •  •  ‘v'v  v  *  ' 


ELAPSED  TIME 


3.811 


9,747 


CPU  -  T 
(secs) 

OTAL» 

87 

2,557 

5,798 

CPU  -  D 
(secs) 

BMS 

38 

1,174 

1,468 

BVB  . . 

1,005 

933 

21,312 

RLB 

298 

7,736 

19,005 

WVB 

631 

3,251 

13,760 

WLB 

335 

9,717 

2,686 

LOAD  OVERLAY  _ 

376 

40 

25,473 

BlSL-IQa _ 

4,296 

41,394 

164,787 

ELAPSED  TIME 
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This  paragraph  presents  comparisons  of  the  three  DBMSs'  efficiency  while 
performing  three  general  types  of  activity:  LOAD,  RETRIEVE,  and  UPDATE. 
Multi-user  effects  are  then  examined  using  statistics  gathered  during 
execution  of  the  multi-user  I4W  scenarios.  A  ranking  of  performance  is 
followed  by  discussions  of  the  sensitivity  of  performance  to  operational 
variables,  the  significance  of  observed  and  projected  performance  to  I&W 
requirements,  and  recommendations  for  improvement.  Tables  1 3—6  through 
13-9  contain  statistics  used  during  this  analysis. 

13.2.1  LOAD 

(Test  Series  Z1-Z5) 

13.2.1.1  toiopariaon 

To  acquire  statistics  on  LOAD  performance,  the  J-File  was  loaded  five 
times  with  each  DBMS.  The  number  of  records  loaded  was  doubled  on  each 
load  for  the  purpose  of  developing  a  set  of  curves  representing 
performance  as  a  function  of  number  of  records  loaded.  An  unordered 
flat-file  input  was  considered  the  most  neutral  of  formats  and  was 
therefore  employed  in  all  loads.  It  was  discovered  that  SEED  is  painfully 
sensitive  to  input  structure  and  ordering.  The  input  it  was  presented 
with  is  perhaps  the  worst  it  could  experience.  With  a  small  amount  of 
effort,  a  user  site  could  pre-process  data  to  better  suit  SEED,  probably 
bringing  it  up  to  the  load  efficiency  of  ORACLE  as  observed. 

The  unequivocal  winner  of  the  LOAD  competition,  however,  is  ADABAS-M.  Its 
performance  in  LOADing,  when  compared  to  that  of  the  other  two  DBMSs,  is 
dramatic;  for  example,  ADABAS-M  took  316  seconds  of  elapsed  time  to  load 
4,950  records,  compared  to  7,726  seconds  for  ORACLE  and  23,181  seconds  for 
SEED.  In  addition,  the  elapsed  time  (and  other  measures)  for  ADABAS-M,  as 
a  function  of  number  of  records  loaded  appears  to  be  very  close  to  linear. 
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A  projected  figure  of  approximately  8,000  seconds  for  ADABAS-M  to  load 
approximately  150,000  records  gives  support  to  the  vendor's  claim  of 
100,000  records  loaded  in  1  1/2  hours.  ORACLE  appears  to  exhibit  a  slight 
increase  in  elapsed  time  per  record  as  the  number  of  records  increases 
(.025  seconds  increase  per  record  per  doubling),  whereas  SEED  appears  to 
incur  an  additional  second  per  record  for  each  doubling.  Using  these 
numbers  to  project  would  give  266,909  seconds  (74  hours)  for  ORACLE  and 
1,494,965  seconds  (415  hours)  for  SEED  to  load  approximately  150,000 
records.  The  SEED  number,  it  must  be  remembered,  is  an  absolute  worst 
possible  case. 

13.2.1.3  Significance  to  I&W  Requirements 

Since  loading  the  data  base  is  essentially  a  one-time  chore,  the 
efficiency  of  this  process  is  not  terribly  important,  assuming 
time-to-load  is  kept  within  reasonable  bounds.  The  74  hours  projected  for 
ORACLE  to  load  150,000  records,  for  example,  is  considered  reasonable  in 
that  it  represents  approximately  three  days  of  non-stop  loading,  a  not 
unusual  experience  when  loading  intelligence  data  bases.  As  mentioned 
before,  it  is  anticipated  that  SEED,  with  favorable  organization  of  input, 
could  perform  just  as  well. 

13.2.1.4  Recommendations-  for  Improvement 

Obviously,  ADABAS-M  is  in  no  need  of  improvement  for  loading  of  data.  It 
is  apparent  that  ORACLE  is  maintaining  index  entry  order  during  load.  If 
this  is  true,  efficiency  could  probably  be  enhanced  dramatically  by 
waiting  until  the  end  of  input  has  been  reached  to  sequence  and  organize 
the  indices. 


13.2.2  fimirn 

(Test  Series  A,D,M,N,0,P,Q,R) 

13.2.2.1  Comparison 

Retrieval  results  indicate  that  the  basic  access  algorithm  of  ADABAS-M  is 
inferior  to  both  ORACLE  and  SEED,  but  that  ADABAS-M’ s  query  resolution 
logic  is  superior.  In  the  Simple  Query  (Test  Series  Q)  where  a  majority 
of  the  records  pass  qualification  (3,415  out  of  4, *50),  SFED  wins  handily 
since  it  can  CALC  directly  to  owner  records  of  interest  and  retrieve  data 
records  using  pointers  found  in  the  owner  records.  In  this  case,  all 
records  read  are  known  to  pass  qualification  before  they  are  accessed,  so 
no  effort  is  wasted.  ORACLE  must  incur  overhead  in  searching  to  acquire 
record  pointers,  but  this  overhead  is  smaller  than  that  of  ADABAS-M. 

These  observations  are  based  primarily  upon  RVB  (Read  Virtual  Block)  and 
RLB  (Read  Logical  Block)  counts  for  the  three  DBMSs  for  Test  Series  Q 
(5,991,  3,716  and  2,037,  respectively).  The  three  time-associated 
measures  (CPU-DBMS,  CPU-TOTAL  and  ELAPSED  TIME)  show  an  even  greater 
disparity,  and  support  the  previous  analysis,  indicating  that  there  are 
not  only  more  disk  operations  associated  with  indexing  than  with  hashing 
(no  suprise),  but  that,  since  the  CPU  times  are  greater  per  RVB/ RLB 
performed  in  the  indexing  models,  it  can  be  supposed  that  the  logic 
supporting  indices  is  more  involved  and  costly  than  that  supporting  hashed 
access. 

A  mystery  persists  in  Test  Series  Q  and  was  also  observed  in  Test  Series  M 
and  0.  During  this  simple  retrieval  of  3,415  records,  ADABAS-M  performed 
7,040  Load  Overlays  (L0V)  (14  more  were  performed  outside  of  ADABAS-M). 
There  is  no  need  in  the  single  program  user  environment  of  this  test  for 
rolling  programs  in  and  out.  Indeed,  in  Test  Series  R,  identical  to  Q 
except  for  added  query  qualifications,  this  behavior  was  not  observed.  It 


was  thought  that  perhaps  ADABAS-M  was  using  the  LOV  as  a  more  efficient 
means  for  reading  data  records  or  Indices.  Since  all  of  the  LOV  activity 
is  to  the  system  disk  rather  than  the  data  disk,  the  use  of  LOV  to  read 
qualifying  data  records  must  be  discarded.  Since  Test  Series  R  must  have 
accessed  indices  at  least  as  much  as  Test  Series  Q,  and  since  R  employed 
only  2 56  LOVs,  this  hypothesis  was  also  rejected. 

One  hypothesis  which  has  not  been  rejected  is  that  the  ADABAS-M  design 
emphasizes  and  expects  a  multi-user  environment,  and  optimizes  for  this 
environment  to  the  detriment  of  the  single  user,  "batch",  type  of 
operation.  It  may  automatically  save  its  buffer  by  rolling  it  out  to  disk 
every  time  a  new  record  comes  in.  This  action  would  be  taken  under  the 
assumption  that  the  current  buffer  contents  belong  to  a  user  other  than 
the  user  who  owns  the  record  coming  in.  In  this  case,  it  cannot  be 
assumed  that  the  user  of  the  original  buffer  is  finished  with  its 
contents.  The  buffer  must  be  saved.  A  simple  check  should  be  possible  to 
discover  whether  or  not  the  user  has  changed.  If  the  same  user  is 
requesting  another  record,  it  can  be  assumed  that  the  original  buffer 
contents  are  no  longer  needed  and,  therfore,  do  not  need  to  be  saved. 

The  only  other  unrejected  hypothesis  is  that  the  LOV  activity  is 
associated  with  maintenance  of  the  bit  map  employed  for  recording  hits. 
If  for  some  reason  a  bit  map  is  being  rolled  in  and  out,  via  LOV,  each 
time  a  record  qualifies,  the  activity  could  be  explained.  This 
explanation  would  require,  however,  that  for  a  compound  query  such  as  Test 
Series  R,  ANDing  on  results  of  multiple  key  searches  is  performed  before 
bit  maps  are  rolled  out. 

The  picture  for  compound  queries  is  markedly  different.  In  contrast  to 
the  analysis  above  concerning  basic  access  algorithms,  it  can  be  observed 
in  Test  Series  R  that  the  query  resolution  algorithm  employed  by  ADABAS-M 
is  far  superior  to  those  of  both  ORACLE  and  SEED.  In  going  from  Q,  which 
retrieves  3*415  qualifying  records  to  R,  which  retrieves  19  qualifying 


records,  ADABAS-M  elapsed  time  drops  by  95  J,  ORACLE  by  50* ,  and  SEED  time 
doubles.  All  other  measures  are  similar.  It  is  obvious  from  the  results 
of  Test  Series  R  that  ADABAS-H  resolves  the  entire  query  via  its  indices 
before  reading  data  records.  ORACLE  appears  to  be  reading  data  records 
based  on  intermediate  results  derived  from  part  of  the  query,  and  then 
qualifying  further  by  examination  of  the  record. 

The  schema  definition  employed  for  SEED  was  the  cause  of  SEED'S  poor 
showing  in  Test  Series  R.  As  defined,  the  search  keys  involved  (place 
name  and  country  code)  had  no  direct  relation  to  each  other.  Had  the 
schema  associated  place  names  as  a  set  subordinate  to  the  country  code 
set,  SEED  would  have  performed  much  better,  employing  a  hash  to  country 
code  and  a  short  chain  walk  (in  this  data  base)  to  the  place  name.  It  was 
felt,  however,  in  the  schema  design  phase  of  the  project  that  requests  for 
messages  by  location  would  normally  be  by  either  country  code  qxl  place 
name,  not  both,  since  the  place  names  of  places  of  interest  in  an  I&W  data 
base  are  generally  unique.  Where  they  are  not  unique,  the  additional 
retrievals  for  duplicative  place  names  were  felt  to  be  less  of  a  burden  to 
the  system  than  extensive  chain  walking  in  a  large  data  base  that  would 
occur  if,  for  instance,  TYARATAM  were  to  be  sought  in  the  chain  of  all 
places  recorded  as  being  in  the  USSR. 

Test  Series  A  and  D  were  Collection  Coordination  scenarios  each  simulating 
one  terminal,  starting  with  identical  seeds.  The  difference  in  the  two 
was  that  A  was  to  modify  qualifying  records  and  D  was  to  delete  them.  In 
the  event,  neither  scenario  found  the  correct  combination  of  qualifying 
records  from  the  G,  H  and  J  files  to  trigger  its  modifying  or  deleting 
activity.  A  total  of  61  records  were  retrieved  on  simple  criteria  from 
the  3  files.  ADABAS-M  outperformed  ORACLE  approximately  2  to  1  in  these 
tests.  SEED  was  not  tested. 
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13*2.2.2  Sensitivity  to  Operational  Variables 

ADABAS-M  appears  to  be  poorly  suited  to  list  processing  types  of  activity, 
where  long  lists  of  records  are  manipulated.  It  is  ideally  suited  for 
applications  where  queries  are  complex  and  the  number  of  records 
qualifying  is  low.  The  bulk  of  ADABAS-M  effort  is  expended  in  accessing 
data  records  rather  than  in  finding  them.  From  test  results,  it  would 
furthermore  seem  likely  that  a  larger  data  base  would  not  seriously  impair 
the  performance  of  ADABAS-M  in  its  searching  activity. 

ORACLE  took  only  a  little  over  twice  as  long  to  read  3,415  records  as  it 
did  to  read  61  or  19  records.  Unlike  ADABAS-M,  ORACLE  increased  time  from 
Test  Series  A  to  Test  Series  R,  even  though  the  number  of  records 
retrieved  was  smaller  for  R  than  for  A.  This  indicates  that  ORACLE  is  more 
sensitive  to  the  complexity  of  queries  than  to  the  number  of  records 
retrieved. 

ORACLE'S  practice  of  reading  data  records  before  they  are  completely 
qualified  could  get  it  into  serious  trouble  in  a  very  large  data  base. 
Depending  on  the  structure  and  distribution  of  the  data  base  and  the 
nature  of  queries,  ORACLE  could  easily  find  itself  performing  tens  of 
thousands  of  data  record  accesses  needlessly,  thus  slowing  response  to  the 
analyst  drastically  and  saturating  system  resources  for  other  requests. 
This  effect  has  been  avoided  in  intelligence  data  handling  systems  facing 
the  same  problem  by  allowing  only  pre-defined  and  formatted  queries.  In 
doing  this,  however,  the  flexibility  and  power  of  SEQUEL  and  the  data 
model  supported  by  ORACLE,  probably  its  best  features,  would  be 
neutralized. 

SEED  would  be  relatively  insensitive  to  the  size  of  the  data  base  if  all 
keys  were  CALC  keys.  Some  degradation  would  occur,  however,  as  the  size 
of  the  data  base  increases  relative  to  the  available  disk  storage,  due  to 
hash  collisions.  As  queries  become  more  varied,  it  becomes  more  likely 
that  keys  will  not  be  CALCed,  thus  requiring  chain  walking  or  unnecessary 
retrieval  of  records  which  satisfy  only  part  of  the  query  (as  in  ORACLE). 
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At  this  point,  SEED  becomes  very  sensitive  to  the  distribution  of  data. 
Thus,  if  long  chains  exist,  SEED  will  perform  poorly  on  queries. 
Likewise,  if  relationships  between  data  have  not  been  established  at 
schema  definition  time,  SEED  must  perform  extra  work  to  associate  them. 

13. ?.2.3  Significance  to  I&W  Operations 

Since  I&W  analysis  is  currently  characterized  by  queries  of  a  fairly 
standard  and  pre-determined  nature,  it  is  tempting  to  speculate  that  an 
appropriate  data  base  design  using  SEED  would  be  the  most  efficient 
approach.  Two  considerations,  however,  work  against  this  decision.  The 
first  is  that  I&W  activity  to  date  has  to  a  large  degree  been  shaped  by 
the  tools  it  has  had  available  to  it.  If  a  more  flexible  and  powerful 
query  tool  were  available,  queries  might  not  be  so  constrained.  The  other 
consideration  is  the  growing  potential  importance  of  artificial 
intelligence  to  the  I&W  process.  If  artificial  intelligence  capabilities 
are  to  be  introduced  to  enhance  the  effectiveness  of  the  I&W  analyst,  they 
cannot  be  constrained  by  the  inherent  inflexibilities  of  the  CODASYL  model 
demonstrated  on  this  project  by  SEED. 

ADABAS-M  performed  best  of  all  in  the  tests  executed,  except  for  the  Q 
Series,  which  is  not  considered  typical  for  I&W  operations  (long  lists  are 
seldom  retrieved).  In  addition,  ADABAS-M  is  perceived  as  supporting  a 
more  flexible  query  environment  than  SEED  in  that  keys  may  be  designated 
for  all  access  requirements  without  running  into  limitations  which  are 
built-in  (e.g. ,  only  one  CALC  field  per  record)  or  resorting  to  structures 
which  become  cumbersome  in  large  data  base  environments  (e.g.,  chains). 

ORACLE,  while  not  performing  as  well  as  ADABAS-M,  appears  to  be  less 
sensitive  to  the  type  of  query  and  the  most  flexible  of  the  three  systems 
tested.  This  augurs  well  for  the  I&W  environment,  especially  that  of  the 
future. 
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ADABAS-M' s  problems  with  Test  Series  Q  and  excessive  load  overlay  action 
should  be  investigated.  It  is  quite  likely  that  a  minor  modification 
could  solve  the  observed  inefficiencies.  If  the  hypothesis  stated  above, 
that  the  LOV  activity  is  due  to  an  assumption  that  the  environment  will  be 
heavily  multi-user,  is  true,  it  may  not  pay  to  modify  ADABAS-M,  since  the 
I&W  environment  is  a  musti-user  environment.  A  trade-off  investigation 
examining  just  how  heavily  multi-user  the  environment  is,  compared  to  the 
added  CPU  cost  of  knowing  when  a  buffer  need  not  be  rolled  out,  compared 
to  the  CPU  and  I/O  savings  when  roll-outs  are  avoided,  should  be  performed 
before  modifying  ADABAS-M. 

ORACLE  would  benefit  from  additional  logic  which  would  enable  it  to 
resolve  entire  queries  before  accessing  data  records,  as  ADABAS-M 
does.  This  would  be  a  considerable  effort  in  the  best  of  cases.  It  is 
likely  that  the  basic  structures  of  ORACLE  may  not  support  such  a 
modification. 

13.2.3  HECATE 

(Test  Series  B,C,E,F,G,H,I, J,K,L) 

13.2.3.1  Compariaon 

ADABAS-M  performed  better  than  ORACLE  on  every  update  scenario  executed. 
Table  1 3— 9  shows  update  test  statistics  for  ADABAS-M  and  ORACLE,  for  the 
measures:  elapsed  time,  total  CPU  time  (attributable  to  the  DBMS),  and 
file  service  requests.  The  column  "0/A"  is  the  result  of  dividing  the 
ORACLE  statistic  by  the  ADABAS-M  statistic  and  shows  the  advantage  (ratio 
larger  than  1.0)  or  disadvantage  (ratio  smaller  than  1.0)  of  ADABAS-M 
relative  to  ORACLE. 


UPDATE  Performance  (ADABAS-M  and  ORACLE) 


One  overriding  effect  should  be  discussed.  When  ADDing  records  to  the 
G-File,  two  separate  relations  had  to  be  updated  during  the  ORACLE  tests 
due  to  the  limitation  on  size  of  the  SEQUEL  working  area.  This  caused 
extra  command  parsing  and  logic  execution  for  ORACLE,  handicapping  it 
significantly. 

The  degree  of  this  handicap  can  be  seen  in  both  elapsed  time  and  total  CPU 
time: 

o  The  elapsed  time  advantage  range  (ADABAS-M  to  ORACLE)  for  tests 
having  no  ADDs  (Test  Series  B,E,F  and  I)  is  1.5  to  1.9.  The 
range  for  total  CPU  time  is  2.3  to  3.5. 

o  The  elapsed  time  advantage  range  for  tests  which  include  the  50 
record  ADD  (Test  Series  C,G,H,J,  and  K)  is  2.5  to  6.1.  The 
range  for  total  CPU  time  is  3.7  to  6.2. 

Additionally,  it  can  be  noted  that  there  is  a  general  trend  for  the 
advantage  to  drop  as  ADDs  become  a  smaller  proportion  of  total  activity. 
Test  Series  C,  which  shows  the  greatest  advantage  for  ADABAS-M  (6.1,  6.2) 
performs  only  ADDs. 

The  only  advantage  shown  for  ORACLE  is  for  file  service  requests  during 
the  ADD  related  tests,  this  advantage  increasing  as  ADDs  become  a  greater 
proportion  of  the  activity.  This  indicates  that  although  ORACLE  has  a 
relatively  difficult  time  deciding  what  to  do  and  how  to  do  it,  it  is  more 
efficient  in  actually  storing  new  records.  This  condition  of  being 
relatively  CPU  bound  is  born  out  by  page  6  of  Table  13-7,  which  depicts 
CPU  time  versus  physical  I/O  time.  There  is  no  suprise  here.  Since  ORACLE 
supports  a  more  general  data  model  and  more  powerful  (non-procedural) 
interface  language,  it  can  be  expected  to  be  more  CPU  intensive. 


Examination  of  Table  13-10,  which  orders  tests  according  to  resouce 
utlization  and  workload,  will  show  a  very  strong  correlation  of  all  three 
measures  of  ORACLE  resource  utilization  to  the  number  of  commands  issued 
to  the  DBMS.  This  supports  comments  made  above  concerning  the  expense 
involved  in  parsing  a  non-procederal  language  and  supporting  a  very 
general  and  basic  data  model.  The  indication  is  one  of  almost  direct 
correlation.  ADABAS-M  also  shows  a  strong  correlation  of  CPU  time  to  the 
number  of  commands  issued.  Other  ADABAS-M  correlations  are  looser. 

Of  particular  interest  is  the  number  of  seconds  of  CPU  time  used  by  the 
two  DBMSs  per  command.  ADABAS-M  takes  from  1.7  to  4.0  seconds  per  command 
for  more  active  jobs  (C,G,H,I, J,K).  It  is  in  the  5.0  to  8.3  second  range 
for  less  active  jobs  (B,E,F).  ORACLE,  for  more  active  jobs,  takes 
approximately  10.6  to  13.8  seconds  per  command.  For  less  active  jobs,  it 
takes  from  11.9  to  19.0  seconds  per  command.  This  means  that  ADABAS-M 
would  saturate  the  CPU  sometime  before  35  requests  per  minute  are  made  of 
it  from  resident  drivers.  It  would  saturate  the  CPU  sometime  before  12 
requests  are  made  of  it  from  quick  in  and  out  drivers.  ORACLE  CPU  best 
case  saturation  points  are,  respectively,  6  and  5  seconds. 

Another  observation  should  be  made  concerning  the  multi-user 
characterisics  of  ADABAS-M  as  they  apply  to  update  activity.  It  is  the 
practice  of  ADABAS-M  to  maintain  updated  and  new  records  in  primary  memory 
until  they  are  forced  out  by  space  limitations  or  until  ADABAS-M  itself  is 
terminated.  This  practice  was  observed  during  the  benchmark  tests  when 
update  tests  were  run  to  completion  and  their  statistics  blocks  contained 
now  writes  to  the  data  disk.  The  tests  had  to  be  re-run,  with  termination 
of  ADABAS-M,  to  get  valid  statistics.  ADABAS-M  was  still  alive  in  memory, 
idling,  waiting  for  other  jobs  to  request  its  services.  It  was  oblivious 
to  the  fact  that  its  only  user  had  terminated,  and  still  maintained  the 
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updated  or  added  records  in  active  buffers,  assuming  that  until  it 
absolutely  had  to  put  them  on  disk,  it  might  as  well  keep  them  in  primary 
memory  in  case  another  user  requested  them.  Some  savings  may  be  had  here 
if  users  tend  to  access  the  same  records.  This  policy  of  maintaining 
updated  and  new  records  explains  ADABAS-M's  non-optional  journaling  of 
updates.  If  updates  are  not  to  be  made  permanent  (written  to  disk)  at  the 
termination  of  the  job  which  updated  them,  then  some  provision  must  be 
made  to  assure  the  user  that  the  updates  will  eventually  become  permanent 
even  in  the  eventuality  of  system  failure  sometime  subsequent  to 
successful  termination  of  the  update  job.  Automatic,  non-optional  logging 
of  updates  accomplishes  this.  This  logging  activity,  of  course,  uses 
system  resources,  but  it  is  certainly  faster  than  immediate  updates  to  the 
data  base  on  disk.  Logging  activity  can  be  observed,  in  fact,  via  the 
disk  cylinder  access  and  head  movement  histograms  produced  during  the 
benchmark  by  the  General  Purpose  Monitor,  to  be  sequential,  in- track 
writes,  causing  a  minimum  of  costly  head  movement,  usually  none. 

13.2.3.3  Significance  to  I&W  Requirements 

Since  the  I&W  environment  will  likely  continue  to  be  that  of  a  system  of 
resident  application  drivers  and  will  include  direct  calls  to  the  DBMS 
from  terminals,  the  CPU  to  command  ratio  should  be  in  the  low  end.  Thu3, 
taking  the  best  case  for  the  more  efficient  DBMS,  the  system  can  be 
expected  to  support,  at  a  theoretical  maximum,  35  requests  per  minute.  To 
maintain  acceptable  response  times,  this  number  should  be  lowered  to 
approximately  25  requests  per  minute.  This  is  probably  in  range  for 
existing  systems,  but  allows  little  room  for  an  increase  in  the  number  of 
users  and  almost  no  support  for  advanced  techniques  of  automatic  inference 
and  decision  support.  This  is  a  generic  problem  to  all  data  base 
management  services  provided  by  host  resident  software. 
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The  automatic,  non-optional  journaling  policy  of  ADABAS-M  presents  a 
question.  Since  it  makes  possible  a  savings  when  updated  records  are  soon 
accessed  again,  it  is  potentially  a  resource  saving  policy.  It  can  also 
be  said  that,  since  data  integrity  and  security  from  loss  are  important 
considerations,  that  no  resources  are  wasted;  some  form  of  journaling  for 
recovery  must  in  any  case  be  provided.  It  is  possible,  however,  that 
there  may  be  a  desire  to  avoid  the  cost  of  journaling  on  some  files,  as  in 
the  case  of  analyst  work  files,  or  possibly,  to  speed  up  processing  during 
periods  of  urgent  demand. 


13.2.3.4 


It  is  felt  that  there  is  not  much  room  for  improvement  in  resource 
utilization  in  either  ADABAS-M  or  in  ORACLE.  ADABAS-M  appears  rather 
efficient  and  ORACLE  appears  just  as  efficient  considering  the  greater 
power  and  flexibility  it  affords.  Unfortunately,  this  performance  can 
probably  not  be  enhanced  sufficiently  to  meet  algorithmic  and  level  of 
support  enhancements  planned  for  I&W  systems. 
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(Test  Series  F,G,H,I,J,K) 


13.2.4.1 


No  discernable  penalties  were  incurred  either  by  ADABAS-M  or  ORACLE  in  the 
support  of  multiple  users.  Test  Series  F,G,  and  H  all  had  three  users. 
Both  DBMSs  showed  marked  increase  in  system  resource  utilization  during  G 
and  H  as  compared  to  F,  but  G  and  H  also  performed  four  times  as  many 
commands  as  F.  Test  Series  I,  which  has  five  users,  performed  more  in  the 
range  of  F  than  in  the  range  of  J  and  K,  which  had  six  users  each.  Again, 
the  number  of  commands  performed  by  I  was  closer  to  F  than  to  G,H,J  or  K. 
Refer  to  Table  13-6  for  information  concerning  the  numbers  and  types  of 
commands  performed  for  each  Test  Series. 


Although  the  number  of  users  did  not  seem  to  have  great  effect,  a  case 
might  be  made  that  the  number  of  tasks  did  have  an  effect  in  both  ADABAS-M 
and  ORACLE.  The  Test  Series,  which  had  by  far  the  heaviest  resource 
utilization  (G,H,J,K)  also  had  the  highest  number  of  tasks  (3).  It  can  be 
seen  that  I,  which  had  more  users  than  G  and  H,  and  also  accessed  more 
records  than  G  and  H,  was  much  lower  in  resource  utilization  than  they 
were.  Test  Series  I  also  had,  however,  approximately  one  third  of  the 
number  of  commands  to  process.  Again,  the  number  of  commands  processed 
appears  to  be  the  determining  factor. 

As  has  been  discussed  earlier  in  this  report,  the  benchmark  tests  were 
adversely  affected  by  ADABAS-M* s  restriction  of  no  more  than  18  files  open 
at  one  time.  ORACLE'S  requirement  for  a  separate  copy  of  its  user 
interface  module  for  each  terminal  supported  also  impaired  testing.  It 
would  seem  that  ADABAS-M  is  designed  for  a  limited  application  set  and 
ORACLE  for  a  small  number  of  users. 
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Although  no  clear  correlation  of  efficiency  to  number  of  users  was 
discerned,  the  functionality  of  the  systems  in  supporting  large  numbers  of 
users  or  large  application  sets  is  suspect.  Although  ADABAS-M  might 


support  a  large  number  of  users  (this  has  not  been  proved),  they  must 
limit  themselves  to  a  total  of  18  open  files.  ORACLE'S  requirement  for 
embedding  itself  in  user  tasks  could,  at  some  point,  cause  a  shortage  of 
system  memory. 

13.2.4.3  Significance  to  I&K_JteQulrements 


ADABAS-M' s  18  file  restriction  is  severely  detrimental  to  I&W 
requirements.  Net  only  does  it  put  an  unacceptable  limit  on  expandability 
of  I&W  systems,  it  would  not  even  now  support  system  files  and  analyst 
work  files  at  the  same  time. 


ORACLE'S  memory  eating  propensity  probably  puts  an  unacceptable  upper 
limit  on  the  number  of  users. 


13-2.4.4  Recommendations  for  Improvement 

Probably  the  18  file  limitation  in  ADABAS-M  is  an  arbitrary  number  which 
could  be  increased  with  a  minimum  of  effort.  The  limitation  is  placed 
because  a  buffer  is  kept  for  each  open  file,  thus  using  memory  for  each 
open  file.  If  the  subject  I&W  system  has  sufficient  memory,  there  is  no 
reason  why  an  adequate  number  of  files  could  not  be  supported.  For 
example,  assuming  each  buffer  consists  of  512  bytes,  100  open  files  could 
be  supported  at  the  cost  of  only  51 ,200  bytes  of  memory. 

ORACLE'S  problem  is  more  at  the  heart  of  its  design  philosophy 
(multi-tasking  rather  than  multi-serving).  It  would  probably  be  a  major 
overhaul  to  change  it. 


This  section  contains  qualitative  evaluations  of  the  ORACLE,  ADABAS-M,  and 
SEED  systems  from  the  point  of  view  (1)  of  the  user  and  (2)  of  the 
programmer.  Other  comments,  dealing  with  specific  system  features,  are 
included  in  the  first  subsection. 

The  material  contained  in  this  section  is  derived  from  a  full  year’s 
experience  with  each  of  the  systems  under  test,  and  reflects  those 
features  which  may  prove  most  significant  in  the  actual  choice  of  a 
system.  Factors  are  included  which  appear  to  have  the  greatest  potential 
impact  on  system  selection.  No  single  DBMS  was  found  to  be  so  outstanding 
that  it  can  be  recommended  without  qualification  for  all  l&W  analyst 
requirements.  For  this  reason,  this  set  of  qualitative  evaluations  may  be 
used  to  provide  guidance  in  locating  those  features  required  by  a 
particular  installation. 

Subsection  14.1  contains  comments  and  descriptive  material  in  narrative 
form.  Subsections  14.2  and  14.3  contain  evaluations  in  outline  form. 
Recommendations  from  the  point  of  view  of  user-analysts  and  programmers 
are  contained  at  the  end  of  these  two  subsections. 


This  section  contains  narrative  evaluations  of  the  ORACLE,  ADABAS-M,  and 
SEED  systems  along  the  following  dimensions: 


o  Query  Language 


o  Interactive  User  Interface 


o  Host  Language  Interface 


o  Data  Base  Administrator  Utilities 


14.1.1 


The  ORACLE  query  language  is  SQL,  a  version  of  the  family  of  SEQUEL 
languages  developed  by  IBM.  SQL  is  English-like,  containing  many  "noise" 
words  (i.e.  words  which  are  not  needed  in  the  query,  but  which  assist  the 
human  reader,  such  as  "from,"  "where,"  "in,"  etc.)  The  SQL  parser  docs  not 
require  all  the  noise  words,  and  many  words  can  be  abbreviated.  The 
language  is  well  documented,  with  many  examples. 


The  ADABAS-M  query  language,  ADASCRIPT-M,  is  not  English-like  in  the  sense 


that  noise  words  are  not  used  or  required. 


Queries  to  SEED  use  the  Fortran-oriented  Data  Manipulation  Language,  which 
is  neither  user-friendly  nor  English-like.  The  commands  available  for  user 
are  strictly  dependent  on  the  definition  of  the  data  and  relationships 


defined  for  the  data  base. 


14.1.2 


In  ORACLE,  the  SQL  interactive  processor  is  useful  for  debugging  and 
quickly  inspecting  data  base  contents.  However,  it  has  some  undesirable 


features: 


Although  SQL  prints  column  headings  for  a  query,  the  heading  is  truncated 
to  the  length  of  the  field. 


The  data  buffer  size  is  a  hindrance  with  the  IAW  data  base  because  some 


records  are  too  large  to  be  displayed  at  one  time.  When  this  happens,  the 
user  is  forced  to  select  only  certain  fields  for  display.  However,  note 
that  ADABAS-M  does  not  permit  the  user  to  select  fields  for  display,  and 


all  fields  are  always  returned. 
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In  ADABAS-M,  the  interactive  debugging  program  was  used  for  inspecting 
data  base  contents,  as  well  as  for  debugging  and  other  purposes. 

ADABAS-M  use  in  general  is  more  limited  by  the  role  assigned  to  the  Data 
Base  Administrator  (DBA).  The  DBA  must  specifically  define  and  allow  user 
views  for  the  end  user,  open  files  which  the  user  will  be  allowed  to 
access,  and  perform  other  functions  which  restrict  user  access  to  the 
system. 

The  AMTEST  routine  used  by  ADABAS-M  does  not  display  field  headings.  Data 
are  simply  packed  into  a  record  buffer  and  returned  —  all  the  data,  all 
the  time. 

AMTEST  is  much  more  "procedural"  than  SQL;  that  is,  once  into  AMTEST,  the 
user  must  open  a  thread,  open  the  file  that  will  be  accessed,  put  the 
filename  into  the  control  block,  and  specify  the  user  view  that  will  used, 
and  its  length,  before  a  query  can  be  made  against  that  file.  If  a 
different  file  will  be  used,  the  same  steps  must  be  performed. 

AMTEST  allows  the  user  to  save  information  returned  from  a  query  to  a 
user-specified  external  file,  while  SQL  does  not.  In  SQL,  however,  once 
the  user  specifies  the  data  base  name,  then  all  files  in  that  data  base 
are  made  available. 

Two  interactive  query  facilities  are  provided  in  SEED:  HARVEST  and  GARDEN. 

HARVEST  provides  information  about  the  schema/ subschema  definition, 
displays  data  values  of  specified  items  in  the  data  base,  and  performs 
other  functions.  As  in  ORACLE,  the  user  has  the  ability  to  display  only 
selected  fields. 


The  first  step  in  HARVEST  is  to  specify  the  subschema  name  and  password. 
Once  this  is  complete,  the  user  is  connected  to  the  data  base,  and  all 
data  (files,  records,  sets)  are  available.  HARVEST  also  allows  the  user  to 
save  information  returned  from  a  query  in  a  user-specified  file. 

Note  that  HARVEST  is  used  only  to  query  the  data  base.  No  commands  are 
available  for  the  user  to  modify  or  update  the  data  base. 

GARDEN,  the  SEED  on-line  query  facility,  is  best  suited  to  aid  in 
application  development.  GARDEN  provides  an  interactive  Data  Manipulation 
Language  (DML)  which  allows  the  programmer  to  obtain  Information  about  the 
data  base  (sets,  records,  data  items),  test  applications  programs,  and,  if 
necessary,  modify  the  contents  of  the  data  base  interactively. 

An  end-user,  such  as  an  analyst,  would  find  GARDEN  much  too  procedural ly 
oriented.  GARDEN  does  not  provide  an  English-like  query  language  and  can 
only  be  used  with  a  thorough  understanding  of  the  structure  of,  and 
relationships  within,  the  data  base. 

Neither  HARVEST  nor  GARDEN  was  directly  evaluated  during  this  project. 

14.1.3  Hast. -Languags. Interface 

In  general,  ADABAS-M  requires  fewer  calls  to  process  a  query.  Typically, 
the  steps  performed  are: 

o  Open  a  thread  (connect  to  the  data  base). 

o  Open  the  file  to  be  operated  on;  use  the  host  language  to  set  up 

search  buffers  and  other  required  files. 
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o  Issue  the  command  to  the  data  base;  i.e.,  for  a  simple  retrieval 
based  on  a  key  for  an  entire  record,  the  record  contents  would 
be  retrieved  in  a  record  buffer.  The  user  is  then  left  to 
"process"  or  "view"  these  field  values  based  on  relative  field 
positions. 

o  Close  the  file. 

o  Close  the  thread  (disconnect  from  ADABAS-M). 

ORACLE  requires  more  calls  (probably  because  it  is  intended  to  be 
"user-friendly").  In  general,  the  following  commands  are  used: 

o  Log  on  to  ORACLE. 

o  Open  a  cursor  (connect  to  the  data  base). 

o  Issue  the  SQL  command  to  the  parser.  (Use  of  the  parser  reflects 

the  "user-friendly"  approach,  since  the  more  natural  commands 
require  more  processing. ) 

o  Bind  any  search  variables  to  the  command.  (The  ADABAS-M 

equivalent  would  be  to  set  up  the  search  buffer.  In  comparing 
the  two  systems,  notice  that  when  using  the  Host  Language 
Interface  (HLI),  ORACLE  has  the  user  make  several  calls  to 
ORACLE-specific  routines,  in  order  to  check  each  step,  while 
ADABAS-M  has  the  user  make  use  of  the  host  language.) 

o  Define  receiving  fields  for  a  retrieval  instead  of  having 
retrieved  data  dumped  into  a  data  array. 


o  Execute  the  retrieval;  i.e.,  perform  a  search.  However,  the  data 
will  not  be  delivered  without  a  FETCH  command. 

o  FETCH  the  data.  (In  ADABAS-M  the  user  has  the  option  of  passing 
a  record  buffer  in  most  cases.  If  the  buffer  has  been  defined, 
the  data  are  put  into  it.) 

o  Close  the  cursor  (disconnect  from  the  data  base), 
o  Log  off  from  ORACLE. 

In  SEED,  the  steps  required  to  process  a  query  are  generally  very  simple: 
o  Open  the  data  base. 

o  Issue  the  commands  to  the  data  base. 

o  Close  the  data  base. 

This  procedure  would  require  issuing  SEED  DHL  commands  which  are  specific 
to  the  structure  of  the  files  defined  in  the  schema.  That  is,  a  thorough 
knowledge  of  the  data  base  definition  is  required  for  navigation. 

A  simple  retrieval  based  on  a  key  for  an  entire  record  for  the  Weather 
Summary  file  used  in  these  tests  would  involve: 

1.  Finding  the  position  in  the  owner  set  based  on  calc  key  value  (a 
unique  retrieval  key  used  by  a  hashing  scheme  to  calculate  the  location  of 
the  page  address  on  which  the  record  is  placed),  and  then: 


2.  Finding  members  of  that  set  based  on  chaining  methods  defined. 
The  I&W  data  base  has  been  defined  with  only  forward  pointers,  and  would 
find  the  next  positional  member  of  the  set.  The  user  has  the  option  here 
of  simply  locating  the  record  or  using  a  variation  of  the  same  command, 
which  will  transfer  the  data  from  system  buffers  to  the  user  work  area. 

Note  that  with  SEED  running  under  IAS,  it  was  found  that  all  applications 
interacting  with  SEED  had  to  be  taskbuilt  using  "split  task  architecture" 
and  run  from  MCR  (an  IAS  facility)  as  real-time  tasks.  Using  split- task 
architecture,  the  application  is  linked  to  a  vendor-supplied  module  which 
spawns  a  subprocess  to  execute  the  DML  commands. 

One  feature  of  the  SEED  DML  is  that  it  includes  commands  which  allow  the 
user  to  display  diagnostic  messages  when  errors  occur. 

Another,  less  desirable  feature  is  that,  unlike  ADABAS-M  and  ORACLE,  when 
an  error  occurs  in  an  applications  program,  the  user  must  reset  the  error 
status  code  to  zero. 

For  debugging  purposes,  it  is  not  always  necesssary  (or  possible)  to  have 
a  task  execute  "successfully"  or  completely.  Unexpected  errors  may  occur, 
and  the  user  may  abort  the  task.  When  this  happens  in  ADABAS-M,  the  Data 
Base  Administrator  (DBA)  must  use  a  utility  to  close  all  threads  left  open 
by  the  user  (that  is,  disconnect  the  user  from  ADABAS  normally).  When  this 
happens  in  ORACLE,  the  user  and  DBA  need  not  take  any  action,  because  the 
ORACLE  cleanup  task  detects  the  user  task  abort  and  frees  the  data  base 
resources  in  use  by  abnormally  terminating  user  programs  and  terminal 
processes. 
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Host  Language  Interface  (HLI)  documentation  is  always  somewhat  cryptic  at 
first  glance.  For  example,  the  vendors  supply  examples  in  several 
different  languages.  A  problem  would  occur  if  the  actual  implementation 
failed  to  match  specifications.  The  documentation  might  explicitly  state 
(or  even  strongly  imply)  that  certain  parameters  were  optional  in  a 
calling  sequence,  but  experimentation  might  show  that  they  were  necessary. 

An  example  of  this  type  of  difficulty,  in  the  ORACLE  DBA  documentation, 
occurred  when  project  personnel  used  the  ORACLE  EXPORT  utility  to  back  up 
portions  of  the  data  base.  Documentation  indicated  that  certain  parameters 
were  optional  and  could  be  entered  in  any  order.  After  a  great  deal  of 
experimentation,  it  was  found  that  all  parameters  were  actually  required, 
and  that  they  must  be  entered  in  the  correct  order.  In  addition,  it  was 
found  that  after  data  files  had  been  backed  up  with  the  EXPORT  utility, 
they  could  not  always  be  reloaded  with  the  IMPORT  utility,  which  sometimes 
indicated  errors  in  data  formats. 

14.1.4  Data  Base  Administrator  Utilities 

In  general,  for  ADABAS-M,  the  DBA  has  the  ultimate  power  over  use  of  the 
data  base,  and  the  DBA  functions  are  quite  separate  and  distinct  from  the 
functions  that  the  user  is  allowed  to  perform.  This  would  be  an  advantage 
in  an  environment  in  which  the  user  does  not  want  or  need  access  to  the 
data  base  at  a  higher  level.  For  exairole,  a  user  who  wants  to  change  a 
user  view  in  ADABAS-M  must  call  in  the  DBA  to  perform  this  task. 

Although  ADABAS-M  is  not  a  secure  system,  the  DBA  can  severely  limit  the 
data  base  user. 


ORACLE,  as  a  more  user-friendly  system,  allows  dynamic  changes  to  be  made 
in  the  data  base  by  the  user,  and  gives  no  impression  of  a  distinct 
separation  in  roles  between  the  DBA  and  the  user.  ORACLE  does  document  a 
privilege  granting  scheme. 

Which  of  these  systems  is  easier  to  use?  From  the  point  of  view  of  the 
user,  working  interactively  with  the  system: 

o  It  depends  on  the  documentation  available  to  the  user. 

o  It  depends  on  how  well  the  user  knows  the  contents  of  the  data 

base.  (This  is  the  most  important  factor,  since  SEED  requires 
the  user  to  understand  data  base  structure  for  effective  use  of 
the  system. ) 

o  Given  that  the  user  is  an  analyst  at  a  terminal,  trying  to 
process  what  has  been  seen  and  finding  anything  new  based  on 
previous  information,  then  ORACLE  would  appear  to  be  the  easiest 
to  use.  It  might  be  noted  here  that  in  ORACLE  a  query  can  be 
performed  based  on  the  value  of  anv  field,  if  response  time  is 
ignored.  In  ADABAS,  a  query  can  be  performed  only  on  a  field 
defined  as  a  key  field,  and  that  ADABAS  might  be  limited  in  use 
for  ad  hoc  queries  unless  the  user  had  little  imagination  (the 
test  is  in  the  imagination  of  the  data  base  designer).  This 
preference  for  ORACLE  is  also  based  on  the  assumption  that  SQL 
is  being  compared  with  AMTEST,  and  AMTEST  would  require  too  much 
set-up  time. 


Following  completion  of  the  RTE  test  runs  with  ADABAS-M,  the  system 
vendor,  Software  AG,  announced  that  the  system  was  being  withdrawn  from 
further  sales  because  of  possible  errors  in  the  implementation.  It  is  not 
clear  at  this  time  what  the  future  status  of  ADABAS-M  will  be. 

14.2  Analvst-User  Viewpoint 

This  subsection  contains,  in  outline  form,  characteristics  of  the  three 
DBMSs  which  appear  to  be  most  significant  from  the  point  of  view  of  the 
analyst-user. 

o  Interactive  Language 

ORACLE 

—  Easiest  to  learn  and  use  but  only  average  in  execution 
English- like  language 

ADABAS-M 


—  Not  as  English-like  as  ORACLE 

SEED 


Two  interactive  language  options,  one  for  each  type  of 


HARVEST 


-  Very  easy  for  the  non- technical  person  to  use 


—  On-line  HELP  facility  to  aid  the  user 


GARDEN 


—  Resembles  host  interface  language 


-  Requires  programming  background  to  use  and 


understand  it 


o  For  ORACLE  and  ADABAS-M,  the  interactive  language  resembles  the 
host  interface  language.  For  SEED,  one  interactive  language,  GARDEN, 
resembles  the  host  interface  language. 


o  Retrievals  from  non-keyed  fields: 


Cannot  be  performed  under  ADABAS-M 


ORACLE  and  SEED  can  retrieve  on  any  field,  not  just  keyed 
fields.  This  feature  is  important  for  ad  hoc  query  entry 


Data  retrieval  output  facilities 


ADABAS-M 


No  field  headings  or  separation  among  output  items 


Very  difficult  to  read  in  this  form 


Entire  record  is  stored  in  packed  format  in  the  record 


buffer 
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ORACLE 


Field  headings  with  their  values 

If  the  heading  is  larger  than  its  value,  the  heading 
is  truncated.  This  may  cause  trouble  if  two  headings 
have  the  same  initial  letters. 


SEED 


—  Headings  and  field  values 

o  User  views:  versatility  of  facilities  for  creating  unique  views 
of  the  data  base  for  each  user 

ORACLE 

—  Each  analyst  can  create  his  or  her  own  table  or  view 
of  the  data  base  without  changing  the  actual  data 
base. 

ADABAS-M,  SEED 

Cannot  dynamically  create  user  views.  In  ADABAS-M  the 
Data  Base  Administrator  has  a  dedicated  terminal  and 
must  take  down  the  entire  system  to  create  new  user 
views. 


Analyst  aids 


SEED 


—  User-friendly  on-line  Help  facility 
ADABAS-M,  ORACLE 

Reference  manuals  required  for  questions 

Number  of  users 

ADABAS-M 

—  There  is  a  limit  on  the  number  of  files  that  can  be 

open  at  the  same  time.  Users  can  access  only  the  files 
that  are  open  at  the  time. 

ORACLE 

When  the  system  is  used  interactively,  the  number  of 
users  that  can  use  the  system  is  limited.  This 
limitation  may  be  due  to  the  PDP-11/70  implementation 
used  for  testing. 

Overall  evaluation  from  point  of  view  of  user-analyst 

ORACLE  preferred  from  user's  viewpoint 

Able  to  retrieve  on  non-keyed  fields,  best  for  ad  hoc 
queries 


—  Easiest  to  identify  and  retrieve  data 

Provides  relational  joins,  needed  for  ad  hoc  queries 

Easiest  to  learn 

Negative  factor  for  ORACLE 

Limited  data  buffer  size.  If  the  record  is  larger  than 
the  record  buffer  size,  it  cannot  be  displayed 
directly. 


This  subsection  contains  evaluation  factors  seen  from  the  point  of  view  of 
the  programmer  responsible  for  installation  and  maintenance  of  the  DBMS. 


o  Debugging  aids 


SEED 


Prints  description  of  error 

ADABAS-M 

Prints  error  code,  which  must  be  looked  up  in  manuals 

ORACLE 

Prints  error  code  only 


Error  codes  cannot  be  predicted  under  certain 
conditions 


—  Even  with  error  codes,  it  is  sometimes  difficult  to 
determine  the  actual  error 

—  Documentation  concerning  error  codes  less  complete 
than  ADABAS-M  and  SEED 

o  Documentation 

ADABAS-M 

—  One  manual;  describes  host  language  interface. 

—  Commands  given  in  alphabetic  order 
—  No  examples 

—  Well  written,  well  organized,  user  is  kept  in  mind 

ORACLE 

—  One  manual 

—  Many  examples 

—  Many  system  specific  items 

—  Not  well  organized  for  programmer 

—  Understanding  the  manual  requires  that  the  reader  know 
the  query  language 
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Commands  listed  In  alphabetic  order 


Examples  too  simple 

—  Structure  seemed  confusing 

Training  manual  was  required  for  some  information 

—  Documentation  not  up-to-date;  missing  documentation 

may  be  due  to  the  fact  that  SEED  was  modified  for  this 
project  by  the  vendor  for  use  under  IAS  operating 
system. 

Record  retrievals 

ADABAS-M,  SEED 

—  Will  return  record  that  is  being  retrieved 

ORACLE 


Will  not  find  and  get  the  record  at  the  same  time;  two 
commands  are  required 

Changes  to  data  base 

SEED 


If  the  file  structure  changes,  with  fields  added  or 
deleted,  the  data  base  administrator  must  rebuild  the 
system. 


ADABAS-M,  ORACLE 


Changes  have  minimum  effect  on  programs;  it  is 
necessary  only  to  modify  the  INCLUDE  file  and 
recompile 

Interference  among  users 

ADABAS-M 


—  If  a  program  aborts  while  holding  a  record,  this  may 
cause  other  users  to  abort  if  they  are  trying  to 
access  that  same  record.  One  user  can  interfere  with 
other  users. 

ORACLE,  SEED 

Users  are  independent,  cannot  interfere  with  each 
other 

Overall  evaluation  from  point  of  view  of  programmer 

SEED 


Best  for  quick,  short  retrievals;  SEED'S  use  of  calc 
fields  for  data  storage  is  extremely  fast 

ADABAS-M 


Best  for  complex  queries  on  multiple  key  fields 


ORACLE 


Best  compromise  for  efficiency  in  both  simple  and 
complex  queries 


Only  system  to  support  relational  joins  for  ad  hoc 
queries 


This  section  presents  conclusions  concerning  the  applicability  of  the 
three  DBMSs  to  the  I&W  mission.  The  body  of  the  report  should  be 
consulted  for  further  discussion  (Section  1.2)  and  details  (Sections  13.0 
and  1-4.0) . 

15.1  Conclusions 

ADABAS-M,  with  identified  enhancements,  is  capable  of  supporting  typical 
large  I4W  systems  for  the  near  to  mid-term  (+5  years). 

o  It  can  support  approximately  25  I&W  analysts  concurrently  with 
adequate  response  times  (5-10  secs.)  (Section  13.2). 

o  It  has  relatively  efficient  reorganization  capabilities  (Section 
14.3). 

ORACLE,  also  with  identified  enhancements,  is  capable  of  supporting 
typical  small  I&W  systems  for  the  near  to  mid-term  (+5  years). 

o  It  can  support  approximately  five  I&W  analysts  concurrently 
with  adequate  response  times  (Section  13.2). 

o  Its  support  in  terms  of  ease  of  use  and  logical  power  is  the 
greatest  of  the  DBMSs  tested  (Sections  13.0  and  14.0). 

o  Its  flexibility  in  terms  of  data  base  definition  and 

reorganization  is  also  the  greatest  of  the  DBMSs  tested 
(Section  13.0  and  14.0). 


SEED,  because  of  its  complexity  and  inflexibility  of  data  base  design  and 
reorginization,  is  not  appropriate  to  the  I&W  task,  which  requires  great 
flexibility  in  data  base  structure  and  contents. 


Reorganization  is  very  difficult  in  SEED. 


Access  paths  must  be  incorporated  into  the  data  definition, 
effectively  ruling  out  the  support  of  un predetermined  inquiry 


and  research  processes. 


SEED  is  the  most  efficient  in  performing  simple  queries  which 
have  been  anticipated  at  data  definition  time,  but  slows  down 
dramatically  as  searches  become  more  complex. 


None  of  the  DBMSs  were  found  to  be  robust.  All  contained  program  code 
errors  which  caused  either  invalid  results  or  program  or  system  aborts 
(Section  13.0  and  14.0). 


Although  ADABAS-M  is  considered  to  be  the  most  efficient  of  the  DBMSs 
tested,  and  the  only  one  capable  of  supporting  a  large  I&W  implementation, 
it  is  not  apparent  that  it  would  offer  any  advantages  over  currently 


fielded  systems  and  Air  Force  owned  DBMSs  such  as  SARP  V. 


ADABAS-M  and  SEED,  which  was  found  to  be  inappropriate  to  the  I&W 
environment,  are  not  recommended  for  new  I&W  system  development. 


ORACLE  is  recommended  for  interim  I&W  system  development  where  a  small 
number  of  users  require  a  powerful  data  model  and  query  capability,  and 
great  flexibility  in  data  base  re-design  and  reorganization. 
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Detailed  recommendations  for  improvement  of  these  DBMSs  can  be  found  in 
Section  13.2.  All  would  require  more  extensive  stress  testing  and 
debugging  before  they  could  be  fielded. 

It  is  our  judgement  that  the  solution  to  I&W  requirements  for  the  mid  to 
long-term  (beginning  approximately  five  years  from  now)  will  be  found  in 
currently  emerging  data  base  machine  technology  and  future  developments  in 
special  purpose  function  architecture. 
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Appendix  A.  DATABASE  HIGHORDER  INTERACTIVE  LANGUAGE  (DHIL) 

This  appendix  contains  definitions  of  the  DHIL  commands  which  were  used  in 
developing  the  scenarios  for  this  project. 

The  full  DHIL  includes  approximately  100  commands  for  scenario 
specification  and  control.  This  summary  contains  only  those  commands  that 
are  needed  for  interpreting  the  scenarios  in  Appendix  C.  In  the 
definitions  provided  here,  a  brief  description  of  the  command  is  given, 
followed  by  a  specification  of  its  format.  Explanations  of  the  parameters 
are  given  when  they  are  needed,  and  further  comments  describe  the  way  in 
which  the  command  has  been  implemented  in  the  RTE.  Since  the  purpose  of 
the  scenarios  has  been  to  provide  a  basis  for  evaluation  of  the  DBMSs, 
several  of  the  commands  have  been  implemented  simply  as  WAIT  times, 
indicating  that  they  involve  operations  which  are  not  related  to  the  DBMS 
under  test. 

The  following  parameter  names  appear  frequently  in  the  definitions: 

userview  =  the  subset  of  data  upon  which  the  analyst  wishes  to 
perform  an  operation 

fieldname  =  a  field  name,  within  the  userview,  on  which  the  selection 
is  based 

fieldvalue  =  the  value  associated  with  fieldname  when  making  a 
selection  request 

L0G0P  =  optional  when  multiple  selection  criteria  are  required;  the 
logical  operator  used  to  make  the  association  between  multiple 
fieldname/fieldvalues  within  a  selection  request  (AND,  OR) 

RELOP  =  a  relational  operator  (EQ,  NE,  GT,  LT,  GE,  LE) 


A-1 


The  following  DHIL  commands  have  been  Implemented  in  developing  the 
scenarios: 

ADDON:  Add  a  new  record  to  the  data  base. 

ADDON  userview; 

The  assumption  has  been  made  that  to  add  a  new  record  to  the  data  base, 
the  analyst  must  first  call  up  the  appropriate  form,  ENTER  all  relevant 
information  into  the  screen,  then  use  the  ADDON  command  to  update  the  data 
base  with  this  new  record. 

The  Update  scenario  uses  this  command  heavily;  the  translator  should 
devise  an  appropriate  scheme  to  represent  the  data  base  impact. 

ALERT:  Output  message  to  analyst  of  the  number  and  type  of  each  entry  in 
the  queue. 

ALERT; 

The  following  assumptions  have  been  made: 

Each  analyst  has  a  queue  which  will  contain  brief  entries  describing 
messages,  memos,  "chatters,"  etc.,  that  have  been  put  into  Jthe  queue.  DHIL 
provides  a  set  of  commands  for  operating  on  these  queues. 

Every  message  in  the  data  base  will  be  stored  in  one  (and  only  one)  file. 
Messages  are  added  to  this  data  base  file  by  a  "phantom"  process  called 
MSGIN  (MSGIN  will  act  as  the  "update"  scenario). 
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The  process  is  as  follows: 

1.  Get  message  from  external  source. 

2.  Assign  Information  Source  ID  Code. 

3.  Add  new  message  to  data  base  message  file. 

4.  Based  on  addressee  information: 

4a.  Update  the  appropriate  analysts'  queues  by  entering  the 
Information  Source  ID  Code  and  other  necessary  information  (priority, 
title,  etc.) 

4b.  When  in  doubt  about  who  sees  it,  update  the  Watch  Officer's 
queue  with  the  information  as  above. 

5.  Go  to  Step  1. 

CHATTER:  Transfer  current  display  to  another  analyst. 

CHATTER  receiving  LOGIN  identifier  [ ,  receiving  LOGIN 
identifier]; 

This  command  updates  the  receiving  analysts'  queues  and  writes  all 
information  to  external  files.  The  translator  should  generate  a  WAIT  time. 


COMMENT:  Scenario  remarks 


COMMENT  scenario-comments; 

Allows  the  insertion  of  comments  to  give  detail  on  how  or  why  certain 
steps  will  be  performed  in  the  scenario.  The  translator  has  the  option  of 
ignoring  the  comment  command,  or  reproducing  it  within  the  script. 

DELETE:  Delete  the  first  record  that  meets  the  selection  criteria  from  the 
data  base. 

DELETE  ([userview,  fieldname  RELOP  fieldvalue 
[LOGOP  fieldname  RELOP  fieldvalue]]); 

DELETE  without  a  parameter  list  (i.e.  DELETEO;)  will  cause  the  removal  of 
the  currently  accessed  record  from  the  data  base. 

DELETE  with  a  parameter  list  causes  the  translator  to  find  the  record  that 
meets  the  selection  criteria,  then  remove  it  from  the  data  base  (actually 
a  RETRIEVE  (parameter  list);  followed  by  a  DELETEO;). 

userview  and  fieldname  are  standard 

fieldvalue  =  any  valid  field  value  (constant,  character  string, 
etc. ) 

If  no  selection  criterion  is  specified,  delete  the  current  record. 
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DISPLAY:  Display  full  body  of  alert 


DISPLAY  [<alert  number>][into  form  <userview>]; 

This  command  represents  the  analyst  displaying  something  in  the  queue 
other  than  a  message,  because  a  message  retrieval  represents  a  data  base 
access,  while  all  other  types  of  alerts  should  be  stored  in  external 
files.  The  translator  could  set  up  an  arbitrary  retrieval  from  a 
non-database  file,  or  set  up  a  WAIT  time. 

If  <alert  number>  is  not  specified,  default  to  highest  priority  alert  in 
queue.  "DISPLAY  [<alert  number>]  into  form  <userview>"  is  used  to  fill  a 
data  base  record  format  with  the  data  contained  in  the  specified  alert 
queue  entry. 

ENTER:  Used  in  the  RTE  to  simulate  the  analyst  entering  data  into  a 
previously  retrieved  form  (message  form,  collection  request  form,  etc.) 

ENTER  (fieldname  =  newvalue  [,  fieldname  =  newvalue]); 

Only  the  contents  of  the  display  are  modified;  this  command  has  no  effect 
on  the  data  base.  Subsequent  primitive  directives  control  the  disposition 
of  the  data.  The  translator  should  handle  this  command  as  a  WAIT  time. 

FORM:  Display  the  template  format  for  the  specified  user  view. 

FORM  userview; 

This  command  is  used  to  display  a  form  which  will  then  have  information 
ENTERed  into  it  by  the  analyst  (a  sequence  of  steps  used  to  add  a  record 
to  the  data  base).  The  translator  should  show  activity  against  whatever 
files  this  FORM  is  contained  in,  or,  if  this  is  impossible,  simply  execute 
a  WAIT  time. 
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HARDCOPY:  Format  and  transfer  all  of  current  display  to  hardcopy  device. 
HARDCOPY; 

The  translator  should  handle  this  command  as  a  WAIT  time. 

INSERT:  Add  DBMS  items  (values)  to  graphics  display  and  insert  information 
about  those  items  into  data  blocks. 

INSERT  ([class  =  <symbol>] ,[loc  =  <value>],  block  =  <value>); 

Parameters  are: 

class  optional  parameter  used  to  assign  a  symbol  to  an  item 
being  added  to  display. 

loc  optional  parameter:  the  coordinates  of  the  item  being 

added  to  display.  If  not  specified,  default  to  current 
position  of  cursor  or  light  pen. 

block  required  parameter,  used  to  append  a  data  block  to  the 
item  identified. 

The  INSERT  command  is  issued  as  a  WAIT  time  from  the  script. 

MAP:  Generate  map  background. 

MAP  ([LAT  =  <fieldvalue>,  LON  =  <fieldvalue>  /  LOC  =  <location 
name>],  [SCALE  =  <scale>]); 

The  analyst  must  specify  either  LAT  and  LON,  or  LOC,  but  not  both. 

LAT,  LON  =  the  geographic  coordinates  to  be  centered  on  display 

LOC  =  country/region/major  city/ installation  to  be  centered  on 
display 
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SCALE  =  optional  parameter  which  specifies  the  desired  map  scale.  If 
not  specified  default  to  the  largest  scale  (1:20m).  Scales  available  are: 
1:20m,  1:5m,  1:1m,  1:500k,  1:250k,  1:100k,  1:50k,  1:25k,  1:10k,  1:7.5k. 

The  translator  should  make  the  appropriate  retrievals  against  whatever 
data  base  file  this  information  is  stored  in. 

MODIFY:  Change  current  selected  data  base  items  (single  instance) 

MODIFY  (fieldname  =  new  value  [,  fieldname  =  new  value]); 

fieldname  =  the  name(s)  of  the  field(s)  within  the  record  that  should 
be  modified. 

new  value  =  any  valid  field  value  (constant,  character  string, 
variable,  etc.) 

This  command  is  used  to  represent  the  analyst  making  an  update  to  the 
specified  fields  in  the  currently  accessed  record.  The  translator  should 
update  the  specified  record  in  the  data  base. 

PAGE:  Scroll  the  display  image  forward  or  backward  one  "page"  at  a  time. 
This  command  is  used  for  the  RTE  to  simulate  the  ai alyst  pressing  the 
appropriate  function  key  for  scrolling. 

PAGE; 

The  translator  should  handle  this  command  as  a  WAIT  time. 


PERFORM:  Execute  a  function  and  return. 

PERFORM  function/procedure/subroutine  name; 

The  translator  should  replace  the  PERFORM  command  with  the  appropriate 
FORTRAN  CALL  statement. 

PLOT:  Retrieve  DBMS  items  and  display  on  previously  generated  map. 

PLOT  ([userview,  fieldname  RELOP  fieldvalue  [LOGOP  fieldname  RELOP 
fieldvalue] ] ,  CLASS  =  symbol,  [BLOCK/NOBLOCK]); 

Retrieve  multiple  instances  of  data  that  qualify  by  the  specified 
selection  criteria  and  plot  onto  current  map  display. 

CLASS  =  classification  of  symbolic  data  to  be  presented. 

BLOCK/NOBLOCK  =  optionally  specifies  that  a  data  block/tag  is  to  be 
appended  to  each  symbol  generated  for  display.  (BLOCK  is  the  default.) 

The  translator  should  generate  commands  for  the  necessary  data  base 
search/retrieval  based  on  the  selection  criteria  specified. 

PLOT  without  selection  criteria  (PLOT  (,  CLASS  =  symbol, 
[BLOCK/NOBLOCK]);)  allows  the  analyst  to  plot  the  information  associated 
with  the  record  currently  being  displayed.  The  translator  handles  this  as 
a  WAIT  time. 

QUERY:  Select  specified  data  (multiple  instances  -  list  display). 

QUERY  (userview,  fieldname  RELOP  fieldvalue  [LOGOP  fieldname  RELOP 
fieldvalue],  [SORT  BY  fieldname  [ASC/DESC]  ] ) ; 
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The  parameter  list  follows  the  standard  definition. 

QUERY  will  retrieve  all  records  in  the  data  base  that  meet  the  selection 
criteria  and  display  them  sequentially  to  the  user  in  SORTed  order  (if 
specified)  with  scroll  capability.  The  translator  should  perform  the  steps 
required  to  access  the  specified  records,  and  perform  the  SORT  (if 
specified)  on  those  records  found.  (For  the  RTE,  SCROLL  is  represented  by 
the  PAGE  command.) 

RECALL:  Return  the  most  recently  STOREd  display  (from  the  top  of  the  STORE 
file)  to  the  terminal. 

RECALL  [STORE]; 

If  the  optional  parameter  STORE  is  given,  the  current  display  will  be 
STOREd  after  the  top  display  is  RECALLed. 

The  translator  handles  the  RECALL  by  reading  the  top  "display"  (mo3t 
recently  stored  display)  from  the  STORE  file,  displaying  it  to  the  user, 
and  removing  this  information  from  the  STORE  file.  In  the  RTE,  the  second 
step  (displaying  the  information  to  the  user)  is  omitted. 

If  the  STORE  parameter  is  given,  move  the  current  display  information  to  a 
temporary  file,  perform  a  RECALL,  then  STORE  the  information  from  the 
temporary  file  to  the  STORE  file. 

RETRIEVE:  Retrieves  the  first  occurrence  of  a  record  that  meets  the 
selection  criteria  (from  userview) ,  and  displays  it  to  the  analyst  through 
the  userview. 

RETRIEVE  (userview,  fieldname  RELOP  fieldvalue  [LOGOP  fieldname  RELOP 
f ieldvalue] ) ; 
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The  translator  should  perforin  the  steps  required  to  access  the  specified 
data  base  record. 

REVIEW:  Retrieve  and  display  next  record  of  data  that  qualify  by  the 
selection  criteria  in  the  previous  SEARCH  statement  (get  next  record  (in 
SORTed  order)  from  hit-list).  When  end  of  data  io  reached  transfer  oontrol 
to  statement  following  END-SEARCH. 

REVIEW; 

The  translator  will  handle  the  SEARCH/REVIEW  pair  according  to  the  types 
of  data  base  access  commands  available  for  each  DBMS. 

ROUTE:  The  ROUTE  command  is  used  to  notify  an  analyst  (<receiving  login 
identifier^  that  the  specified  message  should  be  seen  by  inserting  the 
information  associated  with  that  message  into  the  alert  queue. 

ROUTE  (LOGIN- ID  =  <receiving  login  identifier^  MSG-ID  = 

<fieldvalue>,  PRI  =  <fieldvalue>,  SUBJ  *  <fieldvalue>) ; 

The  ROUTE  command  is  issued  as  a  WAIT  time  from  the  script. 

SCAN:  Display  short  titles  of  all  queued  alerts. 

SCAN; 

Since  these  queues  will  not  be  implemented  for  the  RTE,  the  translator  can 
substitute  a  WAIT  time. 

SEG:  Draw  a  line  segment  between  two  points. 

SEG( [FROM-LAT  =  <f ieldvalue>,  FROM-LON  =  <f ieldvalue>] ,  TO-LAT  = 
<fieldvalue>,  TO-LON  =  <fieldvalue>) ; 


Notice  that  the  FROM  coordinates  are  optional  parameters.  If  not 
specified,  the  assumption  is  that  the  analyst  has  identified  the  FROM 
coordinates  with  the  current  position  of  the  cursor  or  light  pen. 

The  translator  executes  a  WAIT  time  for  the  RTE. 

SOMETIMES:  Used  to  support  the  RTE  by  "randomly"  determining  (using  a 
pseudo-random  number  genrator)  whether  or  not  the  associated  set  of 
commands  should  be  executed. 

SOMETIMES  (probability,  [A],  [LOOP  =  <integer>]); 

probability  =  a  real  number  (hard-coded  into  the  scenario)  which 
assigns  the  probability  of  some  "event"  occurring,  i.e.  that  the  commands 
contained  within  the  following  BEG-SOME  and  END-SOME  delimiters  will  be 
executed. 

A  =  optional  parameter  which  when  present  indicates  that  the  alert 
status  should  weight  the  probability.  For  the  RTE,  it  is  assumed  that: 

PEACE  implies  that  probability  =  probability 

CRISIS  implies  that  probability  =  probability  *  2  or  probability 
=  1 ,  whichever  is  less. 

WAR  implies  that  probability  =  probability  *  3  or  probability  = 
1 ,  whichever  is  less. 

LOOP  =  <integer>  is  an  optional  parameter  which  when  present 
indicates  that  the  SOMETIMES  command  should  be  repeated  <integer>  times, 
with  the  probability  weighting  each  iteration.  The  default  is  a  single 
iteration. 
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This  approach  always  presumes  that  a  "higher"  alert  status  increases  the 
probability  of  all  events  occurring. 

SOMETIMES  is  used  with  the  BEG-SOME  and  END-SOME  primitives  (for  compound 
statements).  The  translator  should  set  up  a  SOMETIMES  function  which,  when 
called,  will  calculate  the  "overall"  probability  (probability  •  A)  and  use 
a  random  number  generator  to  determine  if  the  event  should  occur,  so  that 
translation  should  produce: 

IF  (SOMETIMES  (PROB,  A))  THEN  (*sometimes( )•) 

BEGIN  (#beg-some#) 

•  «  •  i  •  • 

END  (*end-some*) 

STORE:  Save  the  current  display  for  later  RECALL.  The  STORE/RECALL 
primitives  act  as  stack  operators  (PUSH  and  POP  respectively  to  a 
temporary  file)  always  acting  on  the  top  of  the  stack/file  (last  in,  first 
out) . 

STORE; 

The  translator  should  handle  this  command  by  writing  the  current  display 
information  to  the  top  of  a  temporary  store- file. 

Up  to  three  displays  may  be  STOREd  at  one  time;  if  an  analyst  attempts  to 
STORE  a  fourth  display,  delete  the  bottom  display  from  the  STORE  file, 
then  STORE  the  new  display. 


THINK:  Simulates  "think-time"  by  generating  a  random  number  of  seconds  to 
WAIT. 

THINK  (min,  max,  [A]); 

min  =  minimum  number  of  seconds  to  WAIT 

max  =  maximum  number  of  seconds  to  WAIT 

A  =  optional  parameter,  representing  alert  status,  which  when 

specified  weights  min  and  max  as  follows: 

PEACE  implies  min  =  min,  max  =  max. 

CRISIS  implies  min  =  int(min/2),  max  =  int(max/2) 

WAR  implies  min  =  int(min/3),  max  =  int(max/3) 

This  command  is  used  to  represent  the  time  lapse  which  occurs  during  a 
scenario  when  an  analyst  reads  something,  waits  for  hard  copy,  decides 
what  to  do  next,  takes  a  coffee  break,  etc.  Use  of  the  A  parameter 
simulates  the  effect  that  alert  status  has  on  an  analyst's  activity. 

Table  A-1  contains  detailed  instructions  for  the  translation  of  DHIL 

statements  into  FORTRAN  script  elements. 

To  ensure  adequate  managerial  visibility  into  the  progress  of  code 

translation,  testing  and  implementation,  and  to  act  as  a  common 
communication  medium  for  the  different  translators,  a  module-by-module 
tracking  system  was  implemented.  As  each  module  would  flow  through  the 
cycle  from  module  design  to  final  acceptance  of  the  code,  its  current 

status  would  be  indicated  in  an  on-line  report  file. 


I  OHIL  STATUS.TXT  Section  2  > 

dbns:  adabas  -  h  dependent 

Itod-Na*  Description  Teet  Date  Author  Stilus  Conent 

MATCH  I  MATCH-FUNC  I  SEEN  I  9/27  1(200.111  Tst  I  SCENARIO  CONFIETE  !!! 

REVW  I  REVIEW-INPUTS  I  FUNC  I  9/14  1(200.111  Tst  IIV.AA 

DH1S6  1  CGHP-NSG-NOLD  I  F1JNC  I  9/17  1(200.111  Tst  I 

- 9 - , - 1 - ( - ( - * - 

RVEVNT  I  REVIEW-EVENTS  I  FUNC  I  9/23  1(200.111  Tst  I  !  opens  second  thread 

- ( - 1 - 1 - 1 - » - 1 - - 

EXS1ND  1  EXAH-S1GN-IND  I  FUNC  1  9/23  1(200.111  Tst  I  '  opens  second  thread 

- 1 - 1 - 9 . 1 - 1 - 9 - 

SETOPS  I  GET-CRNT-OPS  I  FUNC  I  9/22  1(200.111  Tst  I  !  opens  second  thread 

PRMHSS  I  PREP-WARN-HSG  I  FUNC  I  9/23  1(200.111  Tst  I  'TIKE  for  uniaue  key 

—adds  records  to  all  A-files.  then  deletes  the*  before  returning  to  iainline 

- , - 1 - 9 - 9 - 9 - 9 - 

UPDFIL  I  UPDATE -FILES  I  FUNC  1  9/22  1(200.111  Tst  1  1  updates  E001A 

- 9 - 9 - 9 - 1 - 9 - 9 - 

I  AREA-ANALYSIS  SCENARIO  I 

- 9- - 9 - 9 - 9 - - — 9 - 9 - - - 

AREA  I  AREA-ANALYSIS  I  SCRIPTI  9/30  1(200.111  Tst  I 

- 9 - 9 - 9 - 9 - 9 - 9 . 

CMPHLD  I  CONP-HOLOINGS  I  FUNC  I  9/29  1(200*111  Tst  1 

UPDTOB  I  UPDATE-OB  I  FUNC  I  9/17  1(200.111  Tst  I 

- 9 . 9 - 1 - 9 . 9 . 9 . . 

AM. DAT  I  ADDL-DATA-REQD!  FUNC  I  9/30  1(200*111  Tst  I!  opens  second  thread 

- 1 - 9 - 9 - 9 - 9 - 9 . 

0ETCAP  l  SET -CAPABILITY!  FUNC  1  9/29  11200.1V.  1st  1 

ACTIND  I  ACTIVE-INDICA  I  FUNC  I  9/20  1(200.111  Tst  I 

- 9 - 9 - 9 . 9 - 9 - 9 . 

COLREO  1  COLL-REO  I  FUNC  I  9/29  1C200.UI  Tst  I 

- 9 - 9 - 9 - 9 - 9 - 9 . 

PLTRTE  I  PL0T-FLT-R3UTE1  FUNC  I  9/29  1(200.111  Tst  I IV 

- 9 - 1 - 9 - 9 - 9 - 9 - 

NSMJPI  I  HISSIQN-UPDATEI  FUNC  I  9/28  1(200.131  Tst  I 

- 9 - 1 - 9 - 1 - 9 - 9 . . 

EXXINB  I  EXANINE-INDICAI  FUNC  I  9/27  1(200.111  Tst  I 

- 1 - 9 - 9 - 9 - 9 - 9 - * - 

PREHSS  I  PREPARE-HSG  I  FUNC  I  9/28  1(200.131  Tst  llseae  as  PRUH3G  above 

- 9 - 9 - 9 - 9 - 9 - 9 - - 

I  IU-ANALYSIS  SCENARIO  I 

- 9 - 9 - 9 - 9 - 9 - 9 - 

IMANAL  I  IM-ANA VLSIS  I  ScriptI  7/12  I  I  Code  I 

FNDACT  I  FIND-ALl-ACTIVI  FUNC  I  7/12  I  I  Cod*  I 

MARE  I  BOUND-AREA  I  FUNC  I  7/12  1  I  Code  1 

- 9- . -1 - 9 - 9 - 9 - 9 - 

PLTAOB  I  PLOT-AOB  I  FUNC  I  7/12  I  I  Code  I 

C0HT1N  1  CWWE-TIlt  I  FUNC  I  7/12  I  I  Code  I 


Tphlc  A-l  Trar.slct  ion  of  DVIL  Etatcrcrcs  (rare  2  oE  9) 


KEKTEH  I  REROUTm/HOLDll  EUNC  I  9/2?  lC2G3.ni  Tsl  1'  REE.OUT.  but  hold  tec 

. — . * - * . 1 . 1 .  1 . . . - 

FOR  THE  VERSION  Of  THE  COLLECT 10N-C00RHNAT IOM  SCENARIO  THAT  UF PATES  RECORDS 
AS  THET  ARE  fROCESSEP.  LINK  E 200 . nCOlt-EX  KITH  C200.I5TDHIL/IB. 

-  . I - - -4 . t - 1 - 1 . F - - - 

I  UPDATE  SCENARIO  I 

- E— . -E . E - 1 . f . -I . - . - . . 

UPDATE  I  UPDATE  1  SCEN  I  7/20  I  I  Code  I 

-  . I— . —  1 . 1 . 1  . 1 .  --E - - - 

ADDMSG  I  APD-HSG-T0-D8  I  FUNC  I  7/19  I  I  Cod*  I 

- E . . E .  E . E - E . E .  . — - . 

DELETE  I  DELETE  hSGS  I  FUNC  I  7/21  I  I  Ruf.  I 

-  . -E - - E . -E . E - 1 - 1 . . . 


SCI>  "S 

. E . --E . E- . E . -  E - 1 - - 

A5ACON  I  ADAP-AS  Cotton  I  INCl  I  4/2  I  JUT  I  Tst  I  MsUs  ccit jr.icalion 

- . E .  -E - E - E-  E - E . . 

AIATWO  I  2nd  CTRL PK  I  INCL  I  7/19  I  I  Cod*  1  fur  cirdf  stitches 

. E . t . E . --E - E- . E .  . 

SIMPLE  -  multiple  (100)  simple  retrievals  against  the  "J-Eile"  (weather  info.) 
based  on  a  random  single  key  value  (country  code). 

COMPLEX  -  multiple  (100)  complex  queries  against  the  "J-File"  based  on 

four  randomly  generated  key  values  (place  name  1  and  country  code  1  OR 
place  name  2  and  country  code  2). 
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DBAs:  ORACLE  -  DEPENDENT 

Hod-Nj»  Description  Type  Dele  Autlior  Status  Coitent 

- ^ - 1 - 1 - 1 - 4 . 4 - 

I  COLLECTION-COORDINATION  SCENARIO  I 
- 4 - 4 - 4 - 4 . , - . 

colcor  i  cat -coord.  i  scen  i  a/?  i  i  Tst  i 

- 4 - 4 - 4 - 4 - 4 - 4 . 

EXTREQ  I  PROCESS -KQANTS I  FUNC  18/91  I  Tst  I 

- 4- - 4 - 4 - 1 - 1 - 4  Note: 

GETCA  I  GET-AUTH-FOKN  I  FUNC  I  8/11  I  I  Tst  I  all  source  for  ORACLE 

- 1 - 4 - 4 - 1 - 1  - . 4  resides  in  1200.71 

REJECT  I  REJECT-REQUEST!  FUNC  18/9  1  I  Tst  I 

- 4 - 4 - 4 - 4 - 4 . 4 

REROUT  I  REROUT -REQUEST  I  FUNC  18/9  1  I  Tst  I 

- 4 - * - ( - 4 . * - 4 - 

REVRCE  I  REVIEN-RECCE  I  FUNC  I  8/9  I  I  Tst  I 

- 4 - - 4 . 4 - 4 - 4 . 4- . 

COLLECTION-COORDINATION  StU/DELETEIt 

- 4-- . - . 4 - 4 . 4 . 4 . 4 . 

COLDEl  I  cat -COORD  (DEL)  SCEN  I  10/8  I  I  Code  I 

- 4 . 4 . 4 - 4 . -4 . -4 . 

BTDEl  I  EXT-PROC-DEL  I  FUNC  I  10/8  1  I  Code  I 

- 4 . 4 - 4 . 4 . 4 . 4 . 

ABO-TO-THE-G-FILE  (50  records  to  support  the  COLDEL  scenario) 

- 4 . - . 4 - 4 . 4 - i . -4— . 

ASDTOG  I  AOD-TO-G-FIlE  I  SCEN  I  10/14  I  I  Tst  I 

- 4— . 4 . 4 . 4 . 4 . 4 .  . 

NIL-SrS-ANAl  SCENARIO 

—  . 4 - 4 . 4 . 4 . 4 . 4 . 

NILSYS  i  NIl-STS-ANAl  I  SCEN  I  8/24  I  I  Run  I 

. 4 . 4 . 4 . 4 . 4 . 4 . 

PLOTSS  I  P10T-SANS  I  FUNC  I  8/30  I  I  Run  M  2  open  cursors  ' 

- 4 . 4 . 4 . 4 . 4 . 4 . 

PLOTRS  I  PLT-RADAR-SITEI  FIHC  I  8/30  I  I  Run  I  !  2  open  cursors  ' 

- 4 . - . 4 . 4 . 4 . 4 . 4 . 

UP  DR  I  I  UPD-RADAR-INFO!  FUNC  I  3/10  t  I  Tst  I 

- 4 . . 4 . 4 . 4 . 4 . 4 . 

UPSYSD  I  UPD-SYS-DATA  I  FUNC  I  8/11  I  I  Tst  I 

- 4 . . 4- . 4 - 4 . -4 . 4 . 

OWtSHS  I  OVERLAY-NSNS  I  FUNC  I  8/24  !  I  Run  I 

- 4 - 4 - 4 . 4 . 4 . 4 .  - 

UPDSAN  I  UPDATE -SAN -INF I  FUNC  I  8/24  I  I  Run  I 

- 4- . . 4 - 4 . 4 - 4 . 4 . 

AREA-ANALYSIS  SCENARIO 

- 4 - - 4 . 4 - 4 . 4 . 4 . 

AREA  I  AREA-ANALYSIS  I  SCEN  18/1?  I  I  Run  I 

- 4 . . 4 - 4- . 4  . 4 . 4 . - . 

PL  TRIE  I  PLOT-FlT-ROUTE!  FUNC  I  8/10  I  I  Tst  I 

—  . 4 . - . 4 . 4 - 4 . 4 . -4 . . 

CNPHLD  I  CONP -HOLDINGS  1  FUNC  I  8/17  I  I  Run  I 

- 4-- . 4 . 4 - 4 . 4 - 4 - - - 

ACL  DAT  I  ADDL-CATA-REQDI  FUNC  I  3/31  I  I  Run  I  '  2  open  cursors  1 

- 4— . 4  - . 4  . 4 - 4 - 4 - - 

UPOTOt  I  UP DATE -Cl  I  FUNC  I  8/17  I  I  Run  I 

- 4 . . 4 . 4 . 4 - 4  . 4 . . 


i  6rr<jm.ncsi  fuc  i  b/is  i  i  rut.  i 

I  ACItVATE-lM)  I  FUC  I  8/18  I  I  Sir,  I 


I  COU-RFO  I  FUC  I  8/18  i 

I  HISSION-'.'FDATEt  FUC  I  8/18  I 

. — 4 - 4- . 4- 

I  CKAM-IHOICATOR1  FUNC  I  8/18  I 

--4 - , - 4~ . 4. 

UATCH-FUMCTION  SCENARIO 

I  NATCH-FUNCTIONI  SC£»  1  ?/l  I 


1  Sir,  I 

-4 . 4- 

I  Sir,  I 


I  Rur,  I 

-4 - 4- 


I  REVIEW-INPUTS  I  FISC  1  8/1?  I 

-4— . 4 - 4 - 4- 

I  CONP-NSC-HOU  1  FUNC  I  8/24  I 


I  Run  I  else  used  by  AREA 

-4- . 4 . — - . — ■ 

I  Run  I 


I  REVIEW' EVENTS  I  FJNC  I  8/25  I  1  Code  I 

-4 . 4 - 4 . 4 - 4 - 1 

I  EXA44-SIGMF-IHOI  FUNC  I  8/28  I  I  Run  I 


I  GET-CURRENT -0?  I  FUC  I  8/27  I 

-4 . 4 - 4 . 4- 

I  UPDATE -f ILES  I  FUNC  1  8/27  I 


1  Rur,  I 

-4 . 4- 

I  Rur,  I 

-4 . 4 


I4AC-ROUTE-ACCESSNENT  SCENARIO 

-4 . . 4 . 4 - 4 . 4 . 4- 

I  ItAC -ROUTE  I  SCEN  I  9/1  1  I  Rur,  I 


1  RlOT-HSN  1  FUNC  1 

-4- . 4- . 4- 

I  COUNTRY- 1  WO  I  FU4C  I 


1  Rur,  1 

-4- . 4- 

I  Run  I 


I  SEARCH-08  I  FUNC  11 

-4 . -  - . 4 . 4- 

I  FIND-STS-CAR  I  FUNC  I 

-4- . 4 . 4- 

I  OUERY-INDICAT  I  FUNC  I 


I  Rur,  M2  on-r,  cursors  1 
-4 . 4 . - . 

I  Rur,  I 


I  Rur,  I  1  2  or-er,  cursors  1 


I  SEWCH-EVENTS  I  FUNC  I 
iu- analysis  scenario 


1  Rur,  1  1  2  ore,  cursors  1 
-4 . 4 . . 


I  FIND-AU-ACTVTT  FUNC  I 

-4 . 4 . 4- 

I  BOUND-AREA  I  FUNC  I 


-4 - 4 . . . 

I  Run  I  1  2  orer,  cursors 


i  rue  I 

-4 . 4- 


1  Ron  I  1  2  oeer.  cursors  ' 

4 . -4 . 

I  Run  M2  over,  cursors  ' 

-4 . 4- . . 


SCI>  "R 

- 4 - -4 - 4 - 4 . 4 . 4 . 

AtUVl  I  Al.l  uservieu  I  IIG.  1  8/1?  I  field  deft.s.  Tor  retrievals  or,  AOOl.l 

. 4 - - 4  . 4 . -4 . 4 - 4 . ---- . 

8IUV1  I  81.1  uservieu  I  INa  I  8/25  I  se»e,  but  Tor  user.ie-  8001.1 

. 4- . 4 . 4 . 4  - 4 - 4 . . - . — 

C1UV1  I  CM  uservieu  I  INa  I  8/17  !  seee,  but  for  uservieu  C001.1 

- 4 - 4 . 4  - 4- . 4-  -•  -4 . 

D1W1  I  01.1  uservieu  I  INI  I  8/?  1  se»e>  tout  for  uservieu  DOOM 

- 4 - 4 . 4  . 4- . 4 . 4 . . . 

D2W2  !  D2.2  uvervirv  I  I*Cl  I  8/25  I  se*e,  tot  for  uservieu  D0C2.2 

- 4 - 4 - 4 - 4- - 4  -4 . 

EH1V1  I  EM  uservieu  I  I»a  I  8/25  I  ssee,  b,t  fo'  uservieu  ESCI.l 


T.if'M  A  1  Trane.  1  at  ion  <-!  'I'M  M  •  rent  s  r 
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E2UV1  I  £2.1  overview  1  I  NCI  I  8/U  I 

- 4~ . *——-4 - 4 

£?W3  J  £2.3  uservic*  I  INCl  1  8/16  J 

. 4 . . . 4 . 4 - 4- 

F1UV1  I  Fl.t  userview  I  INCL  l  8/18  I 

- 4 - 4 . -4 - 4 

G1UV1  I  Gl.l  uservieu  I  INCl  I  8/3  I 

. 4 . . -4- . 4- . 4 

G1UV2  I  61.2  userviw  I  INCl  I  8/3  I 

. -4 . - . 4- -4 - 4 

H1UV1  I  HI .1  uservieu  I  INCl  I  8/3  I 

. 4 - - - 4 . 4 - 4 

I2UV1  I  12.1  userview  l  INCl  l  8/4  I 

- 4  - - - 4 - 4 - 4 

J1UV1  I  Jl.l  overview  I  INa  I  8/3  I 

- . -4 . . -4 . -4 - 4 


but  for  i-.trvitw  £002.1 

. 4 - 4 . . 

hut  for  u  £002.3 

- 1  t- 

^oie»  hut  for  Overview  f 001.1 

4  4 . . 

sue i  hut  for  <js?rvieu  G001.1 

- 4 - 4—- . 

sate i  but  for  <ji*:view  G001.2 

- 1 - 4 - - 

uiei  but  for  u.ervieu  H001.1 

- 4 - 4 . . . 

siie»  hot  for  u-cf*ie«  1002.1 

--  4 - 4  - - 

Silei  but  for  interview  J001.1 
- 4 - 4 . . . 


SIMPLE  -  multiple  (IOO)  simple  retrievals  against  the  "J-File"  (weather  info.) 
based  on  a  random  single  key  value  (country  code). 

COMPLEX  -  multiple  (100)  complex  queries  against  the  "J-Kile"  based  on 

four  randomly  generated  key  values  (place  name  1  and  country  code  1  OR 
place  name  2  and  cour try  code  2). 


> 

PHIL  STATUS. TXT 

Stclion  4 

t 

pehs: 

SEED  -  HEfENDENT 

Nod-NoS  Description 

Type  Dale  Author 

SUtus  Cotunt 

i . 

i  t  —i — 

-»-■  — t . — . — 

SlMFl.El  -  multiple  (100)  simple  retrievals  against  the  "J-File"  (weather  info.) 
based  on  a  random  single  key  value  (country  code). 

SI.MPl.K2  -  multiple  (100)  simple  queries  against  the  "J-FilcM  (weather  info.) 
based  on  a  random  single  key  value  (place  name). 

COMPLEX  1  -  multiple  (100)  complex  queries  against  the  "J-File"  based  on  four 

randomly  generated  key  values  teredo  1  and  place  1  OR  c c ode  2  and  pl.o  < 

with  access  via  the  country  code  set. 

COMPI.KX2  -  multiple  (100)  complex  queries  against  the  ''J-File"  based  on  f  *ui 

randomly  generated  key  values  (erode  1  and  place  2  OR  u  uh-  ?  and  | !a  « 

with  access  via  the  place  name  set. 

COMPLEX  with  1  I*  HATH  -  the  otnplex  queries  were  performed  against  t  he  "'I  tie"  and 
the  records  found  whi.  h  met  the  select  ion  r  i  iter  i  • 
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1 

DHIL  STATUS. HI 

Section  3  1 

Dens: 

ANY 

hod-Mj*  Description 

Tsee 

Date 

Author 

Status 

Content 

ALERT 

1  ALERT 

1  DHIL 

1  4/7 

1  JUT 

1  Tst 

i 

PAGE 

1  PAGE 

1  DHIL 

1  S/21 

t  JUT 

1  Tst 

i 

ROUTE 

1  ROUTE 

1  DHIL 

I  7/23 

1 

1  Tst 

1  wait  3  to  7  secs. 

SCAN 

1  SCAN 

1  DHIL 

1  3/24 

1  JUT 

1  Tst 

STORE 

1  STORE 

1  DHIL 

1  4/28 

1 

1  Tst 

1  uait  2  to  5  secs. 

THINK 

1  THINK 

1  DHIL 

1  5/24 

1  JUT 

1  Tst 

1 

FORK 

1  FORK 

1  DHIL 

1  7/2? 

1 

l  Tst 

1  uait  2  to  7  secs. 

HRDCPY 

1  HARDCOPY 

I  DHIL 

1  D/18 

1 

1  Tst 

1  wait  2  to  5  secs. 

RTEHSG 

1  ROUTE-HSG 

1  FUHC 

1  7/14 

1 

1  Tst 

IAAiUATCH 

ST0HS6 

1  STO"E-HSG 

1  FUNC 

1  7/14 

1 

1  Tst 

IAA.UAT04 

STOHAP 

1  STORE  NAP 

1  FUNC 

1  7/14 

1 

1  Tst 

IAA.UATCH 

EQUALA 

I  Strins  Co»i>ar  I  UTIL 

1  4/7 

-E . 

I  4/2 

1  JUT 

1  DECUS 

-F - 

1  JUT 

1  Tst 

1 

-4 . - . 

1  Also  used  in  BNBi  DEG 

RND 

1  Rando»  Hu»ber  1  UTIL 

1  Tst 

-* . 

1  Tst 

CHPRS 

1  Co»eress 

1  UTIL 

1  4/3 

1  Spaces.  Tabs.  Nulls 

EVEN 

1  Evens  inteser 

1  UTIL 

I  4/7 

1  JUT 

1  Tst 

1  Adds  one  to  odds 

ANDLST 

1  ‘AND1  2  lists 

1  UTIL 

1  4/3 

1  JUT 

1  Tst 

1 

WEST 

l  Cotpress  list  l  UTIL 

1  4/3 

l  JUT 

1  JUT 

1  Run 

1  Run 

1  Gel  rid  of  blanks 

DELLST 

1  Delete  entry 

1  Frees  lists 

1  UTIL 

1  4/3 

1  Delete  a  value 

FREEST 

1  UTIL 

1  4/3 

I  JUT 

1  Run 

1  Frees  up  lists 

-4- . - . 

1  Gut  values  fro.  list 

6ETLST 

1  Set  values 

1  UTIL 

1  4/3 

1  JUT 

1  Run 

6IVLST 

1  Gives  a  list 

1  UTIL 

1  4/3 

!  JUT 

1  Run 

1  Gives  a  hit  list 

QPNLST 

l  Oeen  a  list 

1  UTIL 

1  4/3 

-» - 

1  4/3 

1  JUT 

1  Run 

-4 . 

1  Run 

1  MODES  HOT  UORKM  RGP 

- - 

1 

ORLST 

1  •OR'  2  lists 

1  UTIL 

1  JET 

PUTLST 

1  Enters  list 

1  ENTER!...) 

1  UTIL 

1  4/3 

I  JUT 

1 

1  Run 

1  Adds  eletent  to  list 

OTTER 

1  DHIL 

-f - 

1  7/1 

H - 

1  1st 

_1 - 

1  uait  5  to  15  secs. 
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circa  i  circui...)  i  wn  1 7/1  1  1  m  1  wt  1  or  1  ucs. 

- 1 - - --( - 1 - 1 . i - . - . 

INSERT  I  INSERT!...)  I  OHR  17/1  I  list  I  wit  2  to  5  secs. 

- 1 - 1 - 4 - { - ,4 - 4 - - - 

AHP  I  AH’  I  OHR  17/11  I  1st  I  wit  2  to  5  secs. 

STS  I  SCSI...)  I  OHR  17/11  I  Tst  I  wit  1  or  2  secs. 

- 1 - - ( - 4- . -1 - 1 - 1 . - . 

CHTTER  I  CHATTER  ...  I  DHIL  I  7/1  t  I  Tst  I  wit  1  or  2  secs. 

- 1 - 1 - 4 - »- . * . ~| . - . 

01SPLY  I  DISPLAY  ...  I  OHR  I  7/1  I  I  Tst  I  wit  1  to  3  secs. 

- 1 — . — . I - f - 1 - 1 . -I - 

PURGE  I  PURGE  ...  I  DHIL  17/11  I  Tst  I  wit  1  or  2  secs. 

- , - - t - ♦ - » - >- . i— . 

RECALL  I  RECALL  I  DHIL  I  6/28  1  I  Tst  I  wit  2  to  5  secs. 

- ( - - t - ( - 1 - 4 - 1 . . - . 

O*0S  I  CHECK  SOURCES  I  FUNC  I  7/2  I  I  Tst  I  used  b*  HIL-SYS-ANAL 

- ( - 4 . 4 . 4 - 4 - 4 . 

HAP  I  IMP!...)  I  DHIL  17/2  1  I  Tst  I  wit  2  to  5  secs. 

PLOT  I  PLOT!...)  I  OHR  17/2  1  I  Tst  I  wit  2  to  5  secs. 

tttttt  used  only  6s  PLOT  coaaends  without  a  selection  list  tUUt 

- 4 - 4 - 4 - 4 - 4 - 4 - - 

PLTHSA  I  PL0T-NE4I-SAN  I  FUNC  I  7/4  I  I  Tst  I  used  bu  HIL-SYS-AIIAL 

- 1 - 1 - * - 1 - * - 1- . - 

CHTNSA  1  CHAT-NEU-SAH  I  FUNC  17/4  1  I  Tst  I  used  be  HIL-SYS-AIIAL 

- 4 - 4 - 4.. . 4 - f . 4 . 

CHTNSI  I  CHAT-HEU-SITE  I  fUNC  1  7/4  t  I  Tst  I  used  bs  HIL-SYS-AIIAL 

- 1 . 1 . 1 . 1- . 4 - 4 . . 

CHATIC  I  CHAT-INC-CAP  I  FUNC  I  7/4  I  I  Tst  I  used  bs  HIL-SYS-ANAL 

- 4 . 4 - 4 . -4- . 4 . 4 . 

PLOTIC  I  PLOT- INC -CAP  I  fUNC  I  7/4  I  I  Tst  I  used  be  HR -SYS -ANAL 

- 4 . --4- . 4 . 4- . -4 . -4 . 

PLTHSI  I  PLOT-NEU-SITE  I  fUNC  17/41  I  Tst  I  used  bu  HIL-SYS-AIIAL 

— . 4 . 4 . 4 - 4 . 4 . 4 . — . 

8UILDH  I  BUILO-NAP  I  FUNC  I  7/14  I  I  Tst  IAA.UATCH 

- 4 - f . 4 . 4 . 4 . 4 . . . 

BRfTXT  I  BRIEf -TXT  I  fUNC  I  7/15  I  I  Tst  IIU.SIATCH 

- 4— . 4 . 4 . 4 . 4 . 4 . 

CHTCOL  I  CHATTER-COORD  I  FUNC  I  7/9  I  I  Code  I  used  bs  AREA 

- 4 - 4 - 4 - 4 - 4 - 4 - 

CHTHAC  I  CHATTER-HAC  I  FUNC  I  7/9  I  I  Tst  I  used  bj  AREA,  IU 

- 4 . . 4-_ . 4 . 4 . 4 . 4 . 

PRE8RF  I  PRESENT-BRIEF  I  FUNC  I  4/17  I  I  Code  I  u,ed  bu  AREA 

- 4 . 4 . 4 - 4 - 4 . 4 . 

HSGIF  I  HSG-INTO-FORH  I  FLNC  I  7/19  I  I  Tst  I  used  bs  UPDATE 

- 4- - - 4 . 4 - 4 . -4 . 4 . 

RANLST  I  RTE-TO-ANALYSTI  FUNC  1  7/19  I  I  Tst  I  used  bs  UPDATE 

- 4 - 4 . 4 . 4 - 4 . 4 . 

RHATCH  I  RTE-TO-HATCH  I  FUNC  I  7/19  I  I  Tst  I  used  bs  UPDATE 

- 4 - 4 - 4 - 4 . 4 . 4 . 

REHOVE  I  REN0VE-HE5SAGE I  FUNC  I  7/19  I  I  Tst  I  used  be  UPDATE 

- 4 - 4— . 4 . 4 - 4 - 4- . . 

GETCI  I  GET-COLL-INFUTI  FUNC  1  4/25  I  I  Tst  I  used  be  COLL-COORD. 

- 4 - 4- . 4 - 4 . 4 - 4 . . 

SCNOUE  I  SCAN-QUEUE  I  FUNC  I  7/15  I  I  Code  I  used  bs  NAC 

- 4 - 4 - 4- . 4 - 4 - , . - 

NFYOPN  I  NOTIFY -OPNS  I  FUNC  I  7/15  I  I  Code  I  used  bs  NAC 

- 4 . —4 - 4 . 4 - 4 - 4 . 

IRFASH  I  KIEF-ASSESSHTI  FUNC  I  7/15  I  I  Code  I  used  b*  HAC 

- 4 - 4 - 4 - 4 - 4 . -4— . 
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The  following  narratives  are  summaries  of  the  scenarios  presented  in  the 
project  document  "Conceptual  I&W  Data  Base  Specification,"  dated  15  July 
1981,  and  later  revised  by  Mc^.  They  are  intended  to  give  the  reader  a 
general  picture  of  the  type  of  activity  described  in  the  scenarios,  and 
should  not  be  used  as  the  basis  for  detailed  implementation  or  study. 
(Appendix  C  contains  a  precise  specification  of  the  scenarios  in  the  DHIL 
format.)  Note  that  three  of  the  nine  scenarios  listed  here  were  not  fully 
implemented  (as  indicated  in  the  title  lines).  The  first  section  (numbered 
B.1)  contains  a  generalized  scenario  for  I&W  analysis  and  is  not  intended 
for  implementation. 

B.1  Generalized  I&W  Scenario 

This  scenario  presents  a  generalized  task  sequence  for  the  I&W  analyst. 
Emphasis  is  placed  on  the  structure  of  I&W  analysis,  rather  than  on 
specific  actions  or  data  requirements. 

The  analyst  has  been  tasked  to  provide  a  specific  analysis.  This  tasking 
may  be  either  a  continuing  responsibility  or  a  special  request.  To  obtain 
appropriate  data  to  support  the  analysis,  the  analyst  must  first  define 
the  bounds  of  time  and  location  of  the  situation  being  analyzed. 

Within  these  bounds,  the  analyst  calls  for  and  reviews  military  activities 
of  a  designated  type  (such  as  troop  maneuvers).  If  no  significant 
activities  are  found,  then  the  analyst  continues  by  searching  for  other 
activities  of  interest.  (Note  that  "significant"  must  be  defined  for  each 
type  of  analysis.  An  event  is  significant  only  within  the  context  of  the 
analyst's  task  assignment.) 


While  reviewing  military  events  of  several  types  within  the  designated 
space-time  boundaries,  the  analyst  finds  a  report  that  may  be  significant 
(such  as  an  increased  number  of  aircraft  sighted  at  a  particular  location 


within  the  area  of  interest).  At  this  point  in  time,  the  significance  of 
the  report  has  not  been  determined,  and  its  correctness  has  not  been 
verified.  The  next  steps  are  intended  to  establish  the  significance  and 
correctness  of  the  report. 

The  analyst  extends  the  search  to  include  earlier  and  later  time  periods, 
reviewing  military  activities  of  various  types  as  before.  If  nothing 
relevant  or  significant  is  found,  the  analyst  eventually  abandons  this 
analysis  and  returns  to  the  earlier  mode,  perhaps  marking  the  report  for 
future  reference.  The  two  modes  might  be  called  "seek"  and  "confirm."  The 
first  is  a  search  for  items  that  suggest  a  hypothesis  of  interest;  the 
second  is  a  search  for  items  that  confirm,  deny,  or  expand  upon  the 
hypothesis.  The  first  mode  is  comparatively  undirected,  somewhat  like  the 
lookout  in  the  crow's  nest  scanning  the  horizon  for  items  of  interest;  the 
second  is  a  directed  search  for  the  required  information,  as  the  lookout 
attempts  to  verify  and  identify  an  obscure  patch  that  appears  in  the 
telescope. 

Another  extension  of  the  initial  search  includes  adjacent  geographical 
areas.  The  expanded  search  may  also  include  related  military  or  political 
activities,  background  information  on  the  area,  and  any  other  relevant 
information.  The  analyst's  search  is  intended  to  obtain  information  which 
confirms,  explains,  and  expands  upon  the  initial  hypothesis.  Additional 
data  may  be  retrieved  from  the  data  base,  data  from  one  file  may  be 
compared  with  dcta  from  another  file,  data  may  be  displayed  and  combined 
with  other  data  against  the  background  of  a  map  on  a  color  terminal, 
graphs  and  histograms  may  be  drawn  to  help  visualize  the  data,  and  various 
statistical  routines  may  be  employed  to  assist  in  the  analysis. 

At  some  point,  which  is  defined  by  the  type  of  confirmatory  data  obtained, 
the  significance  of  the  event,  and  the  time  requirements  for  warning  or 
other  reports,  the  analyst  may  prepare  a  briefing  or  draft  document 
summarizing  the  findings  of  this  search,  including  references  to  the 
sources  of  information  and  relevant  quotations  from  them.  A  report 


generator  and  other  editing  facilities  assist  in  this  task.  The  analyst's 
immediate  superior  normally  reviews  and  approves  the  report,  which  is  then 
prepared  and  transmitted  in  the  appropriate  form.  The  analyst  returns  to  a 
review  of  incoming  message  traffic. 

B.2  Watch  Function 

Identify  and  determine  significance  of  current  and  impending  events  which 
may  require  a  U.S.  military  response,  or  which  may  affect  the  ability  to 
carry  out  a  military  response. 

The  simulated  Watch  Officer  is  reviewing  incoming  messages  within  an 
assigned  area  of  interest  in  order  to  identify  and  report  on  events  which 
may  require  a  military  response  from  the  U.S.  In  general,  the  messages  are 
routine,  but  a  small  fraction  will  be  regarded  as  unusual.  (In  the 
simulation,  a  random  process  determines  whether  to  regard  a  message  as 
interesting  or  unusual.  The  actual  content  of  the  message  is  not  taken 
into  account  in  the  RTE  simulation.) 

When  an  unusual  message  is  identified,  the  analyst  studies  it  closely  to 
determine  whether  further  action  is  required.  This  judgment  is  based  on 
the  analyst's  prior  knowledge  and  general  understanding  of  the  area  of 
concern.  In  most  instances,  there  will  be  no  need  for  further  action,  and 
the  analyst  will  return  to  the  incoming  message  file.  (Again,  a  random 
process  determines  whether  the  simulated  analyst  will  regard  a  message  as 
significant. ) 

A  message  is  received  which  indicates  that  a  coup  appears  to  be  imminent 
within  the  analyst's  area  of  interest.  The  analyst  uses  the  system  to 
retrieve  other  messages  that  deal  with  events  occurring  at  about  the  same 
time  and  place,  and  which  will  serve  to  verify  and  expand  upon  the 
information  contained  in  the  first  message.  The  analyst  also  examines  the 
current  list  of  indicators  for  this  area  to  determine  the  extent  and 
significance  of  the  coup.  A  statistical  algorithm  is  invoked  to  predict 
the  time  of  occurrence  of  the  coup,  based  on  indicator  values. 


The  next  step  for  the  analyst  is  to  determine  whether  friendly  missions 
will  include  flight  routes  which  may  be  affected  by  the  coup.  A  query  to 
the  data  base  obtains  this  information.  Records  concerning  these  flights 
are  marked  for  subsequent  analysis.  The  analyst  now  studies  the  related 
information  that  has  been  retrieved  to  determine  whether  further  attention 
is  warranted.  If  not,  the  analyst  returns  to  the  task  of  reviewing 
incoming  messages.  (The  decision  whether  to  regard  the  impending  coup  as 
significant  is  simulated  by  a  random  process.) 

If  the  coup  will  have  an  impact  on  flights  which  are  within  the  analyst's 
area  of  responsibility,  a  brief  text  is  prepared  and  transmitted  to  the 
Route  Assessment  officer.  The  data  base  is  updated  to  reflect  the  threat 
to  U.S.  flights  and  to  U.S.  nationals  in  the  area.  A  notation  is  added  to 
the  data  concerning  this  country  indicating  that  there  is  an  impending 
coup. 

The  messages  used  during  this  analysis  are  now  returned  to  the  file,  and 
the  analyst  returns  to  the  routine  task  of  reviewing  incoming  messages. 
When  a  predetermined  number  of  messages  have  been  reviewed,  the  scenario 
terminates. 

B.3  Military  Systems  Analysis 

Identify  significant  changes  in  military  system  capabilities  which  may 
require  a  U.S.  military  response. 

The  analyst  is  reviewing  messages  which  are  concerned  with  foreign 
military  system  capabilities.  Most  of  these  are  routine  and  report  recent 
changes,  which  are  entered  in  the  data  base  to  update  current  information. 
Sometimes  a  message  indicates  a  change  in  system  status  which  will  require 
further  analysis  to  establish  its  significance  for  friendly  military 
forces  and  activities.  (The  occurrence  of  significant  changes  is  simulated 
by  a  random  process.) 


Messages  containing  information  on  system  status  are  selected  by  the 
analyst  and  studied  to  determine  the  need  for  confirmation  and  further 
review.  If  further  study  is  warranted,  the  analyst  enters  appropriate 
instructions  to  locate  additional  information  concerning  the  weapon  system 
from  the  Equipment  Summary.  The  range  of  the  system  is  reviewed  to 
determine  the  extent  of  the  threat  that  it  presents. 

The  simulated  analyst  now  consults  with  other  analysts,  using  the  computer 
terminal  to  send  messages  to  persons  with  some  knowledge  of  the  weapon 
system.  From  information  gathered  in  this  way,  the  analyst  uses  the 
terminal  to  build  a  more  complete  picture  of  the  potential  threat.  A 
cartographic  program  builds  a  display  of  the  geographic  area  involved,  and 
the  location  referenced  in  the  initial  message  is  indicated.  In  this 
scenario,  the  equipment  type  is  a  SAM,  and  the  range  of  this  equipment  is 
indicated  on  the  map,  which  is  displayed  at  the  terminal.  A  computer 
algorithm  is  used  to  determine  impact  assessment  by  correlating  the 
capabilities  of  the  missile  installation  with  preplanned  friendly  flight 
routes.  The  analyst  studies  this  information  to  determine  whether  the 
installation  will  have  a  significant  effect  upon  those  routes.  (The 
analyst's  judgment  is  simulated  by  a  random  process.) 

If  there  will  be  a  significant  impact  on  friendly  flight  routes,  the 
analyst  prepares  briefing  material,  extracting  necessary  information  from 
the  data  just  retrieved.  A  warning  message  is  prepared  and  disseminated. 
Flight  routes  are  modified  to  take  account  of  the  new  threat.  The  analyst 
then  returns  to  the  task  of  reviewing  incoming  messages.  After  a 
predetermined  number  of  messages  have  been  processed,  the  scenario 


B.4  Collection  Coordination 


Coordinate  intelligence  collection  requests  with  current  tasking. 

The  collection  coordinator  is  scanning  incoming  messages  which  contain 
requests  for  collection.  These  are  correlated  to  bring  together  requests 
for  the  same  type  of  information  in  the  same  geographic  area.  Available 
reconnaissance  data  are  reviewed  to  determine  whether  the  required 
information  has  already  been  made  available,  and  to  determine  current 
reconnaissance  tasking. 

If  current  requests  will  not  be  met  by  current  tasking,  new  requirements 
must  be  transmitted.  Priorities  are  established  for  the  new  tasks  and 
cleared  with  the  analyst's  division  chief.  A  report  generator  is  used  to 
produce  a  collection  request  form,  which  is  added  to  the  list  of 
collection  requirements.  The  analyst  returns  to  the  earlier  task  of 
reviewing  incoming  requests.  When  a  pre-set  number  of  requests  have  been 
processed,  the  scenario  terminates. 

B.5  HA£-Jtgpte  Assessment 

Review  MAC  current  operations  and  routes,  and  identify  threats. 

This  scenario  represents  the  actions  of  an  analyst  responsible  for 
reviewing  MAC  current  operations  and  routes  to  identify  potential  threats 
posed  by  nations  on  or  near  the  flight  routes.  These  threats  are 
identified  through  the  use  of  information  contained  in  a  file  of  new  SAM 
sites. 

In  this  scenario,  as  the  analyst  is  reviewing  current  operations 
schedules,  it  is  noted  that  an  embassy  evacuation  has  been  ordered.  Since 
any  evacuation  presents  a  relatively  high  risk,  the  analyst  will  perform  a 
detailed  assessment  of  the  route  being  flown  to  determine  what  air  defense 
threats  may  affect  the  mission. 
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The  first  action  of  the  analyst  is  to  retrieve  and  review  the  route  to  be 
used  in  the  evacuation.  The  information  to  support  this  portion  of  the 
analysis  is  obtained  by  retrieving  and  reviewing  the  data  base  file 
entries  for  each  route  segment  identified  in  the  initial  message. 

Next,  the  analyst  reviews  all  the  data  retrieved  to  determine  whether 
planned  MAC  missions  are  threatened.  If  the  analyst  determines  that  no 
threat  exists,  the  scenario  returns  to  the  beginning;  if  there  appears  to 
be  a  threat,  the  analysis  continues.  (This  decision  is  simulated  by  a 
random  process.) 

The  next  step  is  to  begin  building  a  composite  display  at  the  terminal. 
Cartographic  data  for  the  area  of  interest  are  used  to  create  a  map,  and 
various  overlays  are  constructed  on  the  map.  Among  these  are:  aircraft 
routings,  restricted  areas,  order  of  battle  information,  and  terrorist 
data.  The  information  used  to  construct  these  overlays  is  contained  in  the 
data  retrieved  by  the  initial  queries  to  the  data  base. 

Once  maps  and  overlays  have  been  constructed  for  the  area  of  interest,  the 
analyst  will  continue  with  the  threat  evaluation  previously  begun.  If 
there  appears  to  be  a  threat,  the  analyst  uses  the  computer  system  to 
contact  operations  personnel  concerned  with  the  flight  under  examination 
to  determine  the  degree  to  which  they  are  aware  of  the  threat. 

After  consulting  with  the  operations  staff,  the  analyst  prepares  a  Route 
Threat  Summary  consisting  chiefly  of  the  information  contained  on  the  map 
and  overlays  developed  earlier  in  the  session.  Next,  the  analyst  prepares 
a  Flight  Following  Log. 
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The  analyst  now  monitors  ongoing  message  traffic  pertinent  to  the  MAC 
mission  being  tracked  to  determine  whether  the  original  threat  assessment 
should  be  changed.  If  there  is  an  increased  threat,  the  additional 
information  is  communicated  to  operations  personnel.  A  warning  message  is 
prepared  and  transmitted. 

The  analyst  then  prepares  a  mission  summary  using  information  contained  in 
the  warning  message.  Once  the  data  base  has  been  updated,  the  analyst  will 
return  to  the  routine  planning  task  with  which  the  scenario  began.  When  a 
pre-set  number  of  executions  have  been  completed,  the  scenario  terminates. 

B.6  im  Analysis 

The  analyst  is  reviewing  incoming  message  traffic,  updating  routine 
message  files  as  required.  An  occasional  I&W  input  message  requires 
further  analysis,  and  such  a  message  is  selected  by  the  analyst  from  the 
input  queue  and  stored  in  a  temporary  file.  The  analyst  next  turns  to  a 
file  of  current  holdings  for  a  review  of  other  related  events.  If  no 
related  information  is  available,  the  search  parameters  are  extended,  and 
the  search  continues  until  there  is  sufficient  collateral  information  to 
provide  a  context  for  the  message. 

After  a  careful  study  of  this  related  Information,  the  analyst  uses 
graphics  software  to  build  a  flight  map  for  the  area  under  study.  The  AOB 
is  queried  to  obtain  data  from  which  flights  over  this  area  are  plotted. 
An  algorithm  for  impact  assessment  is  invoked,  identifying  flight  routes 
of  friendly  missions.  These  flight  routes  are  plotted  on  the  map  displayed 
at  the  analyst's  terminal.  After  further  study,  the  analyst  may  decide 
that  a  warning  will  be  required.  (This  decision  is  simulated  in  the 
scenario  by  a  random  process.) 


The  analyst  discusses  the  situation  with  the  collection  coordinator  to 
determine  whether  further  information  may  be  obtained.  Next,  the  indicator 
list  is  reviewed  to  find  out  whether  any  relevant  indicators  have  been 
triggered.  On  the  basis  of  information  already  gathered,  the  analyst 
updates  the  indicator  list.  Next,  the  flight  routes  of  friendly  missions 
are  reviewed  to  determine  the  times  at  which  potential  conflicts  may 
occur.  Using  computer  generated  map  displays,  the  analyst  now  presents  a 
briefing  on  the  apparent  threat  to  friendly  missions.  Following  approval 
from  the  division  chief,  the  analyst  prepares  a  warning  message  using 
editing  facilities  available  at  the  terminal,  and  the  warning  is 
transmitted  through  on-line  message  dissemination  facilities. 

The  scenario  maintains  a  count  of  messages  transmitted.  When  this  count 
exceeds  a  pre-set  number,  the  scenario  terminates;  otherwise,  the 
simulated  analyst  returns  to  the  task  of  reviewing  input  messages. 

B.7  Area  Analysis 

The  analyst  is  reviewing  incoming  messages  at  the  terminal.  Many  of  them 
are  irrelevant  or  routine  and  require  no  more  than  routine  treatment, 
using  storage  facil  ities  available  from  the  terminal.  A  message  is 
received  which  indicates  an  increased  alert  status  at  an  East  German  air 
field,  and  which  appears  to  require  a  more  extensive  analysis.  The  analyst 
temporarily  stores  this  new  message. 

The  analyst  now  compares  the  input  message  with  current  message  holdings. 
Specifically,  the  analyst  enters  a  request  for  information  concerning  the 
status  of  the  unit  at  the  base  which  was  identified  in  the  message.  The 
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information  consists  primarily  of  counts  of  the  number  and  status  of 
various  types  of  aircraft  at  the  base.  If  there  is  no  confirmation  of  the 
apparent  alert,  the  analysis  terminates,  and  the  analyst  returns  to 
routine  message  review.  (The  decision  to  terminate  the  analysis  is 
simulated  by  a  random  process.) 

With  confirmation,  however,  the  analyst  updates  the  file  to  indicate  the 
increased  alert  status.  If  necessary,  additional  data  will  be  obtained  to 
provide  further  information  concerning  the  unit.  (Again,  the  decision  to 
retrieve  further  information  is  simulated  by  a  random  process.)  The 
analyst's  next  request  is  for  a  report  of  all  surface-to-air  missile 
activity  within  a  given  radius  of  the  airfield  under  study.  Cartographic 
capabilities  at  the  computer  terminal  permit  the  analyst  to  build  a  map  of 
the  area,  indicating  SAM  location.  Threat  areas  around  the  SAM 
installations  are  plotted,  based  on  equipment  and  terrain  parameters.  An 
overlay  is  prepared  and  displayed  indicating  the  unit  locations.  The 
analyst  also  notes  that  SAM  sites  and  units  have  been  observed  on 
increased  alert. 

The  analyst  next  consults  with  the  collection  coordinator  to  obtain  any 
further  information,  and  produces  an  impact  assessment.  This  includes  an 
identification  of  HO  friendly  missions  which  may  be  affected  by  the 
observed  enemy  activities.  Friendly  missions  are  plotted  on  the  terminal 
display  against  the  map  background.  The  analyst  now  has  created  a  visual 
display  which  permits  a  study  of  the  effect  of  enemy  activities  on 
friendly  missions.  If  a  threat  is  indicated,  a  notation,  "Watch  for  SAM," 
is  entered  into  the  data  base. 
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If  the  situation  warrants,  the  analyst  next  examines  the  status  of  current 
Soviet  and  East  German  indicators  for  the  area  under  study.  These  confirm 
the  report  of  increased  alert  at  the  first  air  base.  To  document  this 
conclusion,  hardcopy  output  is  produced  from  the  terminal  display.  The 
analyst  updates  the  indicators  to  reflect  the  new  activity.  Next,  the 
analyst  prepares  a  briefing,  based  on  the  information  collected.  A  warning 
message  is  prepared  with  the  aid  of  editing  facilities  available  at  the 
terminal,  and  submitted  to  the  Division  Chief  for  review  and  approval. 
Following  approval,  the  message  is  transmitted,  and  added  to  the  current 
message  files. 

At  this  point,  the  required  analysis  has  been  completed,  and  the  analyst 
returns  to  the  task  of  examining  incoming  messages.  After  a  pre-set  number 
of  messages  have  been  examined,  the  scenario  terminates. 

B.8  Space  Event  Assessment  (not  implemented) 

Determine  possible  threat  associated  with  space  vehicle  launch  which  may 
require  U.S.  military  response. 

The  analyst  is  reviewing  incoming  message  traffic.  For  this  analyst,  space 
vehicles  launched  from  Site  L  are  studied  and  reported.  The  initial  task 
is  to  locate  messages  in  which  the  Launch  Site  Name  is  Site  A.  When  such  a 
report  is  located,  the  information  is  saved  in  a  temporary  storage  area, 
and  the  analyst  requests  additional  data  concerning  activities  at  that 
site  and  nearby  sites  within  a  specified  time  span.  These  additional 
records  are  added  to  the  information  already  saved. 
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Using  the  information  gathered  during  this  search,  the  analyst  calls  upon 
a  support  program  to  compute  the  initial  orbit  of  the  space  vehicle.  Next, 
information  concerning  the  booster  type  of  this  vehicle  is  retrieved 
through  the  system  and  added  to  the  summary  records.  The  completed  Launch 
Event  Summary  is  produced  by  the  system* s  report  generator  and  transmitted 
to  the  analyst's  immediate  superior  for  review  and  approval. 

The  analyst  now  turns  to  other  activities.  The  first  act  is  to  retrieve 
space  vehicle  trajectory  information,  based  on  the  event  identification 
code  of  this  space  event.  A  description  of  the  satellite  is  plotted  on  the 
display  terminal  and  a  subprogram  is  called  to  determine  the  degree  of 
threat.  (The  existence  of  a  threat,  for  the  purposes  of  the  scenario,  is 
determined  by  a  random  process.)  If  the  space  vehicle  does  represent  a 
threat,  a  message  i„*  generated  to  report  the  existence  of  this  threat.  The 
message  is  submitted  to  the  analyst's  immediate  superior  for  approval  and 
dissemination. 


Following  preparation  of  the  warning  message,  the  analyst  returns  to  the 
task  of  reviewing  incoming  messages.  When  the  analyst  has  cycled  through 
this  process  a  predetermined  number  of  times,  the  scenario  ends. 


The  analyst  is  reviewing  incoming  messages,  which  have  been  pre-selected 
as  potentially  relevant  to  missile  threat  assessment.  A  message  concerning 
a  missile  launch  appears  to  be  potentially  relevant,  and  the  next  task 
will  be  to  verify  the  reported  event  and  to  determine  the  threat,  if  any, 
that  the  launch  presents. 

Certain  data  are  reviewed  to  determine  whether  the  missile  type  is  of 
interest.  If  not,  then  the  event  is  recorded,  and  the  analyst  goes  on  to 
review  the  next  record.  If  characteristic  features  of  the  missile  indicate 
that  the  event  is  of  interest,  the  analyst  proceeds  to  review  the  event  in 
greater  detail. 

The  first  step  is  to  plot  the  location  of  the  launch.  A  map  of  the  area  is 
displayed  on  the  terminal,  and  the  location  is  identified.  The  appropriate 
order  of  battle  data  are  retrieved  from  the  data  base,  identifying  the 
missile  through  the  reported  data  and  other  available  information.  The 
equipment  status  summary  is  also  displayed,  and  the  circle  range  is 
computed  with  the  help  of  a  computer  program.  Another  program  is  called  to 
compute  the  trajectory  of  the  missile.  Finally,  information  concerning 
friendly  installations  which  may  be  threatened  by  the  missile  is  also 
retrieved,  displayed,  and  placed  in  temporary  storage. 

Next,  the  analyst  reviews  other  information  which  will  be  used  in 
determining  the  existence  and  extent  of  the  threat.  (In  the  actual 
execution  of  the  scenario,  a  random  process  is  used  to  decide  whether  the 
reported  missile  represents  a  threat.)  If  no  threat  exists,  the  analyst 
returns  to  reviewing  message  traffic.  If  the  analyst  determines  that  there 
is  sufficient  evidence  to  warrant  an  increased  level  of  alert,  this 
information  is  transmitted  to  the  analyst’s  immediate  superior  for 


appropriate  action.  Next,  an  air  defense  alert  briefing  is  prepared,  based 
on  retrieved  information,  using  the  automated  display  and  report 
generation  facilities  of  the  system. 

The  current  list  of  active  indicators  is  modified  to  show  the  launch.  A 
program  is  called  to  compute  residual  threat  based  on  information 
retrieved  from  the  OB.  Other  records  in  the  data  base  are  reviewed  and 
updated  to  show  the  launch.  For  the  purposes  of  the  simulation,  a  count  is 
kept  of  the  number  of  times  the  scenario  has  looped  through  this  sequence 
of  activities.  After  a  pre-set  number  of  loops,  the  scenario  terminates; 
otherwise,  the  simulated  analyst  returns  to  reviewing  incoming  messages. 

B.10  FLINT  Analysis  (not  implemented) 

Determine  possible  threat  associated  with  ELINT  capabilities. 

The  analyst  is  reviewing  ELINT  reports  within  a  designated  area  of 
responsibility.  A  continuing  task  for  this  analyst  is  updating  the  EOB, 
which  is  modified  to  reflect  new  information  received.  The  analyst  next 
calls  on  appropriate  routines  to  plot  the  location  and  coverage  of  a 
specific  radar  installation.  A  map  is  displayed,  and  radar  coverage  is 
indicated,  based  on  data  concerning  the  radar  type  and  terrain 
characteristics . 

The  analyst  must  next  determine  the  threat  posed  by  the  Installation.  (A 
random  process  determines  whether  this  analysis  is  actually  required.)  The 
ELINT  Systems  Summary  is  retrieved  from  the  data  base  to  aid  in  this 
analysis.  Other  analysts  are  consulted  to  obtain  further  information  and 
evaluation.  An  Impact  assessment  is  developed,  based  on  flight  routes  of 
friendly  missions  within  the  range  of  the  radar  under  study.  (In  the 
scenario,  a  random  process  is  used  to  decide  whether  a  threat  is  present.) 


B-n 


rVSS 


If  it  appears  to  the  analyst  that  the  radar  installation  represents  a 
threat  to  friendly  missions,  an  initial  assessment  is  presented  to  the 
analyst's  immediate  superior  for  approval.  Using  the  report  generation 
facilities  of  the  DBMS,  together  with  display  facilities,  the  analyst 
prepares  a  briefing  on  the  Installation  and  prepares  a  warning  message  for 
dissemination.  During  execution  of  the  scenario,  a  count  is  kept  of  the 
number  of  times  this  sequence  of  activities  has  been  performed.  After  a 
predetermined  number  of  executions,  the  scenario  terminates. 

B.11  Updates 

In  addition  to  the  primary  scenarios  described  above,  an  additional 
scenario  provides  a  series  of  updates  to  the  data  base.  The  primary 
purpose  of  the  scenario  is  to  provide  a  flow  of  updates  to  simulate  this 
portion  of  the  load  on  the  data  base  management  system,  to  determine  the 
system's  ability  to  preserve  data  integrity  in  near  real-time  processing. 
For  the  purposes  of  the  simulation,  this  scenario  represents  the  clerical 
task  of  making  new  entries  to  the  OB  files,  indicator  lists,  weather 


Appendix  C.  SCENARIOS  IN  PHIL 


Six  scenarios,  representing  various  types  of  analyst  activities,  based 
upon  the  following  six  intelligence  tasks,  were  defined  in  DHIL  and 
translated  into  scripts: 

o  Watch 

o  I&W  Analysis 

o  Collection  Coordination 

o  Area  Analysis 
o  Military  Systems  Analysis 

o  MAC  Route  Assessment 

This  appendix  contains  complete  DHIL  versions  of  the  scenarios,  together 
with  flowcharts  indicating  the  sequence  of  analyst  actions.  The  flowcharts 
are  contained  in  Figures  C-l  through  C-6,  with  the  accompanying  DHIL 
versions  following  each  flowchart. 


Figure  C-l  WATCH  Function 
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IIWAICH.ORAH 


IE6-SCEN  WATCH-FUNCTION! 

cohment:  ike  hatch  officer  scans  nc  alert  queue 
TO  REVIEW  INC0HIN6  NESSAGESI 
PERFORM  REVIEW-INPUTS i 

COMMENT:  TIC  ANALYST  ANALT2ES  THIS  MESSAGE  TO 
KTERMINE  IF  IT  IS  PERTINENT  TO  THE 
RESPONSIBILITIES  Of  ANOTHER  ANALYST! 
SOMETIMES). 15..)! 

BEG-SOME > 

PERFORM  ROUTE-MSGi 
END-SOME! 

comment:  decide  if  the  message  is  within  the 

FUNCTIONAL  AND  GEOGRAPHIC  AREA  OF 
RESPONSIBILITY  OF  THE  WATCH  OFFICER) 

CAUSING  THE  INVESTIGATION  TO  CONTINUE! 
SOMETIMES). 90>i)i 
BEG-SOME! 

PERFORM  STORE-MSG! 

comment:  the  analyst  requests  tic  air  order 
OF  BATTLE  DATA  FOR  THE  UNIT)S) 
IDENTIFIED  IN  THE  INPUT  ICSSAGEi 
PERFORM  COHP-MSG-HOLDINGS! 

COMMENT:  THE  ANALYST  DECIDES  TO  QUERY  TIC 
EVENT  LOG  FOR  FURTHER  REFERENCES! 
PERFORM  REVIEW-EVENTS! 

comment:  analyst  retried  and  displays 

INDICATOR  LISTS  FOR  ASSESSMENT! 

PERFORM  EXAMINE -SIGNF-INDICATORSI 
comment:  analyst  will  build  map  of  area  of 

CONCERN.  OVERLAY  FRIENDLY  OPERATIONS 
DATA  AND  EXAMINE  ANY  POTENTIAL  I  If  ACT 
BASED  ON  PREVIOUSLY  RETRIEVED  DATA! 
PERFORM  BUILD- MAPI 

COMICNT:  ANALYST  REQUESTS  AND  PLOTS  ALL  INFO. 

ON  MISSIONS  SCHEDULED  IN  TIC  AREAI 
PERFORM  GET  -CURRENT  -CPUS  i 

comment:  tic  analyst  evaluates  this  and  previous 

DATA  TO  DETERMINE  IF  A  POSSIBLE  THREAT 

exists; 

SOMETIMES). 30. A.)! 

KS-SONE! 

COMMENT:  WHEN  A  THREAT  NAY  EXIST.  TIC 
ANALYST  PREPARES  TO  BRIEF  TIC 
BIV-CHIEF/SUPERVISOR! 

PERFORM  SYORE-NAPI 
PERFORM  BRIEF-IEXTI 
PERFORM  PREP-WARNIN6-MSGI 
COMKNT:  THE  ANALYST  MUST  NOW  UPDATE  TBC 
APPROPRIATE  N  FILEISli 
PERFORM  UPOATE-fILESi 
END-SOtCi 
END-SOME! 

END-SCEN  WATCH-FUNCTION. 
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PROCEDURE  NMC:  REVIEV-INPUTS 


MREVINP.ORAtt 


C 

c 
c 

c  abstract: 
c 

C  BEG-FUNC  REVIEIHNPUTS! 

c  comment:  display  number  and  kind  of  eacn  entry  in  oucuei 

C  ALERT! 

C  TH!NK(10.30.A)i 

<•  COMMENT!  DISPLAY  SNORT  TITLE  -  ALL  QUEUED  ALERTS! 

C  SCAN! 

C  THINK(10>30>A)i 

c  comment:  selectively  DISPLAY  and  read  a  message  from 

c  those  routed  through  the  ALERT  QUEUE! 

C  RETRIEVE  <AODl.li  A001I1  EO  *•*)! 

C  THIW(30.PO.A)i 

C  PAGE! 

C  THlNKUOiWiAli 

C  END-PUNC  REVIEH-INPUTS. 

C 

c 


ccccccccccccccccaccccccaccccacaYxaxcaccccaxamcccairaxcccccca: 

c 

C  PROCEDURE  NAK!  ROUTE-MSS  tlRTEMSG.FTNtt 

C 

C 

c  abstract: 

c 

C  BEG-FUNC  ROUTE-MSS! 

C  THINKUOtJOiU 

C  COMMENT!  ROUTE  THE  APPROPRIATE  MESSAGE  I  (FORMATION 

C  TO  THE  RECEIVING  ANALYST'S  ALERT  QUEUED 

C  ROUTEILOGIN  =  T,  MSG-ID  =  AOOltl.  PRI  =  A00II7t> 

C  SUBJ  =  AOOlllPO)! 

C  THINK(S>15>)i 

C  END-FUNC  ROUTE-MSG. 

C 


PROCEDURE  NAME!  STORE -MSS 


USTOMSS.FTNIt 


abstract: 


BEG-FUNC  STORE -MSS! 

comment:  store  the  i*ut  message  in  a  temporary 

PERSONAL  FILE  FOR  LATER  USE! 

STORE! 

END-FUNC  STORE -MSS. 


ccccccccaccccccccccccccccccccaccccccccccccccccccaccccccacccccamccc 


ccccccccccccccccacccccccacccccaccccccccccccccccccccccccccccccccccccca 

c 

PROCEDURE  NAME!  CONP-HSG-HOLDINGS  HCMPHLD.ORAIt 


abstract: 


BEB-fUNC  C0MP-MSS-H0LDIN6S! 

COMMENT!  THE  ANALYST  HILL  REOUEST  SPECIFIC  1*0. 

ON  UNITS  IUP  TO  THREE)  IDENTIFIER  IN 
THE  INPUT  MESSAGE! 

SOMETIMES!. 30. iLOOP  *  ))! 

BEG- some: 

THIMUSilOf!) 

COMMENT!  RETRIEVE  MB  ON  UNIT-NUMBER  AND  CLASS! 
RETRIED (COOl.l.COOltl  EB  *!*  AND  COMM  EB  ’FIS')! 
COMMENT!  ANALTST  READS  THE  INFORMATION! 
THINK!30.?0.A)i 
PAGE! 

THINK(30.f0.A)i 

END-SOME! 

ENB-FUNC  COMF-MSG-NOLDINGS. 


ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 


/V* 


LX* 


si 


PROCEDURE  name:  review-events 


ttlRVEVNT.ORAtlt 


BES-fUNC  REVIEW  EVENTS! 

COMMENT!  THE  ANALYST  REQUESTS  ALL  INFO.  ABOUT  EVENTS  OF  A 
PARTICULAR  TYPE.  OCCURRING  WITHIN  THE  COUNTRY  IN  QUESTION. 
WHERE  THE  PARTICIPANTS  SHOW  AN  ALLE6IANCE  TO  A  PARTICULAR 
COUNTRY  (BASED  ON  INPUT  KSflli 
QUERY (BOOl.li  (B001B23  ED  C001I40  OR  B001I23  EB  *1')  AND 
BOOIBII  NE  *r  AND  8001*32  EB  T)S 
THl«(M.l5«.A)i 
PAGE! 

THIffi  (40. lSOiA)! 

COMMENT!  THE  ANALYST  MAY  REQUEST  FURTiCR  INFORMATION  ON 
PERSONALITIES  INVOLVED  IN  A  PARTICULAR  EVENT! 

SOMETIMES  (.20.  i  IS 
BEG-SOHE! 

SEARCH  <0002.2.  0002*200  EB  B001I2)! 

BEO-SEARCH! 

THINK  (2.5.H 

COMMENT!  Tiff  ANALYST  DISPLAYS  AND  QUICKLY  SCANS  THE  INFO! 
REVIEW! 

THINK  (30.60. A) i 
PAGE! 

THINK  (30.40. A) ! 

END-SEARCH! 

END-SOME. 

END-FUNC  REVIEW-EVENTS. 


.  > 


CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 


cccccccccccaccccccccccccccaaccaccccccacccacccccccccccccccacccccccc 

c 

c  PROCEDURE  NAME!  EXAMINE-SIGNF-INDICATORS  MEXSIND.ORAt* 


.  ' -  -  .  -  . 


abstract: 

BEG-FUNC  EYAMIHE-SIGMIF -INDICATORS! 

COMMENT:  THE  ANALTSr  REQUESTS  COUNTRY  SUMMARY  INFORMATION! 
RETRIEVEIE00I.I.E001B2  E»  COOIB(O)! 

COMMENT!  THE  ANALYST  SCANS  THIS  INFORMATION.THEN  REQUESTS 
ALL  INDICATORS  OF  A  CERTAIN  TTTE  FOR  THIS  COUNTRY! 
QUERTIFOOl.liFOOlIl  EQ  C001M0  AND  FOOU21  EQ  *•*)! 

COMlffNT!  ANALYST  SCANS  INDICATOR  LISTS! 

THINK(30.150.A)i 

PACES 

THINK(30.l50iA)i 

END-FUNC  EXAMINE-SI6NF-INDICAT0RS. 


<  V  V 

>  A  V 


cccccccccccacccccccccccccccccccccccccctaxccacccccccaxcccccccccccccccc 


Sow 

.*  V  ' 


■  V  /.V4  •*.  *V« 


PROCEDURE  NAME*.  BUILD-IW 


tlBUILDH.FTNFI 


BE6-FUNC  BUILD-W! 

cohhemt:  create  nap  BACKGROUND  with  unit 
PLACED  AT  TIC  CENTER  OF  THE  NAP I 
NAPILAT  =  COOlHl.  EON  =  COOmiA.I! 
THlNKdO.IO.I! 

END-FUNC  BUILD -NAP* 


ccccccccccacccccccccccccccccccccccccccccccccccccccctctcccccccccccccccccc 


ccccccccccccccccccccaccccccccccaccccccccccccccccccccccccccccccccccccccc 

c 

C  FROCEDURE  NANE!  GET -CURRENT -OPNS  HIGETOPS.ORAItt 


BEG-FUHC  GET-CUKRENT-OPHSi 

connent:  reguests  all  missions  imose  destination  is  the 

COUNTRY  IN  QUESTION; 

SEARCH! H001.1*H001F7  EG  C001»40>! 
beg-search: 

THINK12.5.  )l 
REVIEWS 

THINK! 120t300>A)> 

CONNENTI  ANALYST  READS  GENERAL  HISSION  INFO,  and 

DECIDES  IF  FURTHER  ENVESTIGATON  IS  NECESSARY! 
S0NET1NES(.80.A.  )! 

BEG-SOHES 

CONNENTI  ANALYST  PLOTS  THE  DEPARTURE  POINT  AND  TAGS 
WITH  THE  HSN-IDi 
PLOT!  .CLASS  =  NSN)! 

THIMM3.10.  )i 
INSERT!  >  .BLOCK  -  H001»2)S 
CONNENTI  THE  ANALYST  DECIDES  TO  DIRECTLY  PLOT  N.L 
END-POINTS  FOR  EACH  HISSION  SEGNENTi 
PlOTdOW.li  1002170  EG  H0CI*2.CLASS  -  'SEG'.NOBLOCK). 
CONNENTI  THE  ANALTST  CAN  CONSTRUCT  THE  ENTIRE  ROUTE 

USING  THE  LICHTPEN  TO  CONNECT  THE  SEG  END-POINTS! 
THINXIS.IO.  I! 

END-SOICI 

END-SEARCH! 

END-FUNC  GET-CURRENT-OPNS. 


accacccccccccccccccccccccccccccccctccccccccccccccccccccccacccccccccccc 


PROCEDURE  NAME!  STORE -IW 


IISTOMAP.FTNtt 


C 

C 

C 

C 

C 

C 

C 

C 

c 

c 

c 

c 


abstract: 

BE6-FUNC  STORE -IMP! 

COMMENT!  STORE  THE  EU.LT  CONSTRUCTED  IMP 
LATER  USE  IN  FRIEFINSSi 

store; 

END-FUNC  STORE -IMP. 


FOR 


cccccccccccccccccccccccccccccacccccccccccccccaccccccccccccccocccoxax 

c 

C  PROCEDURE  NAME:  BRIEF-TEXT  MBRFTXT.FTNtt 

C 

C 

c  adstract: 

c 

C  FE6-FUNC  BRIEF-TEXTI 

C  COMMENT:  ANALYST  DISPLAYS  FULT  CONSTRUCTED 

C  NAP  AND  DISCUSSES  TTC  ASSESSMENT i 

c  recall; 

C  THINMAO.lftiAli 

c  coniient:  analyst  displays  t*  message  that 

C  LED  TO  THIS  CONCLUSION! 

C  RECALL! 

C  THIHKU0.125.AH 

C  END-FUNC  BRIEF- TEXT. 

C 

C 

ccccccccccccaccccccccuccccccccccccttcccccctxaxccccccaxccccccccaccccc 


k\-- 


•V 


y.'- 

y/»\ 

•\V\- 

y  V*  1 


V. 


1C 


UC  «*-**%-  -  ■  M  ..*  a-*  ■ 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


KECEDURE  iKS  PREP-IIARNING-NS6 


UPSVMSG.FTNM 


US--KV. 

BEG-FUNC  PREP-UARNING-MSSi 
COMMENT:  ANALYSE  0ISRAYS  MESSAGE  FORME  AND  EATERS 
APPROPRIATE  DATA! 

FORA  AOOltli 
THINK(5ilO»  )i 

ENTERIAOOltl  =  ’»’iA001»71  =  *I’» 

A 0011190  =  ’UNUSUAL  INDICATOR*! 

A001D200  *  ’MESSAGE  TEXT  -  DETAILS  OF  EV#.UATION’>J 
THINK<30.60>  )t 

comment:  inis  y arming  message  mu  be  added  to  nc  database 

MESSAGE  FILEi  THE  ANALYST  MILL  MARE  A  PERSONAL  CORY. 
THEN  ROUTE  THE  MESSAGE  TO  TIC  SUPERVISOR'S  ALERT 
QUEUES 

ADDON  AOOl.li 
HARDCOPY! 

THINKtSflDi  )» 

ROUTE(LOSIN  =  ’DIV-CHIEF’.MSG'ID  =  AOOlFliPRI  *  ’I’, 

SUBJ  =  ’UNUSUAL  INDICATOR*) i 
END-FUNC  FREP-yARNING-MSS, 


CCattCCCXXXCUCCCCCCCCCC^^ 

c 

p;:cedjre  name:  update-fius  «ufifil.ora« 


A-rRACTi 


BEG-FUNC  UPDATE-FILES) 

TH1NM30iWiA(I 

comment:  the  analyst  decides  to  update  the  country 

SUMMARY  FILE! 

RETRIEVE<E001.1.E001U  E«  C001M0H 
THINK ( 10  r20i ) ) 

MODIFY! £001 tI5  =  ’HI6H*.  EOOlIU  =  ’IMPENDING  COUP’) I 
END-FUNC  IP  DATE-FILES! 


ccccaccccxmccccacccccccccccccccra^ 

c 

KECEDURE  NAME!  ALERT 


ASSHACTJ 


N.ERT  Mill  sioulate  #n  inilwi  disrlivina  nuAbert  ind  types 
c’  Hsiaiei  on  the  Alert  auew.  The  actual  aessases  ire  not  relevant. 


C-8 
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/Si 
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•VI 


'  %  ■ 


r«Wl 


■  V.1 


V.ll l! 


.’V’/’/VW  -»'] 


t./S. 


PROCEDURE  NAHE!  THIW 


C 

C 

C 

C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


abstract: 

THINK  siaulates  an  analyst  ajlind  over  a  decision.  Ikmu  of 
thisi  the  mult  is  divided  bv  the  alert  status.  Obviously.  the 
analyst  uill  think  less  tiee  ir  a  crisis  or  war  situation. 


input: 


KIN 

MX 

ALERT 


-  INTESEa.  Kinioue  react tine  wait 

-  INTEERi  Kaxiauo  wait  at  arm  tioe 

-  lNTE~i  Alert  status  (l»2iJ> 


C 

C 

C 

C 

C 

C 

C 

C 

C 

C 


PROCEDURE  NAME:  SCM 

abstract: 

SCAN  simulates  an  analyst  scanning  throush  the  list  of  alert 
arssases. 


accacccccccacacccccccccccccttaxccccaxcccttccccattcccccccraxaxccc 

c 

C  PROCEDURE  NAHE!  ROUTE  U ROUTE. FT Wl 

c  abstract: 

C 

C  The  DHIl  com  and  ROUTE  is  used  to  insert  aessade  inforaation 

C  into  the  alert  aueue  of  an  analyst. 

C 

C  The  RTE  coaaand  foraal  is! 

C  ROUTEILOGIN  *  <receivind  analyst>>  NSG-IB  =  <f ield  value>» 

C  PRI  =  <field  value>.  SUBJ  *  <field  value»l 

C 

C  Reauired  raraaeters  are! 

C  LOGIN  —  the  lolin  identifier  Use  receivind  analyst 

C  NSG-ID  --  the  asd-id-code  which  leueuely  identifies  a  aessade 
C  within  the  databas 

C  PRI  --  the  aessade  priority 

C  SUBJ  —  brief  inforaation  ind;:atind  the  subJect/content  of 
C  the  aessade 


PROCEDURE  NMC:  NAP 


itwr.nm 


c 
c 
c 

c  abstract: 

c 

C  THE  DMIL  'NAT  COMMAND  IS  USED  TO  SENCRATE  A  AAR  BACKROOM. 

C 

C  THE  RTE  COWARD  FORMAT  IS! 

C  MAP  (COORD  =  <3eo. coords. >  I  LX  *  location  nu*>i 

C  [SCALE  =  <scilt>])i 

C 

C  PARAMETERS  ARE! 

C  COORD  I  LX  -  MUST  SPECIFY  EITHER  COORB  OR  LX  (BUT  ROT  BOTH) 

C  TO  IDENTIFY  THE  CENTER  POINT  X  THE  DISPLAY 

C 

C  SCALE  -  OPTIONAL  PARAMETER  OHICH  SPECIFIES  TIC  SCALE  V  TIC 
C  IMP  TO  BE  DISPLAYED.  SCALES  AVAILABLE  ARE!  1 (DON. 

c  KM.  1:1*.  i:500tc>  1:250*.  1:100*.  1:50*.  1:2s*. 

C  1:10*1  1I7.5X.  IF  NOT  SPECIFIED.  DEFAULT  TO  1!20N 

C 

C 

CCCCCCCCCCCXCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 


CCCCCCCCCaCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCXCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 

c 

C  PROCEDURE  NAME:  INSERT  ttINSERT.FTNtt 

c 
c 
c 
c 
c 
c 
c 
c 


abstract: 

THE  DHIL  'INSERT'  COMMAND  IS  USED  TO  ADD  A  KEN  ITEM  TO  THE 
SPECIFIED  LKATION  ON  THE  CURRENT  NAP  DISPLAY  WITH  A  DATA  BLOCK 
APPENDED  TO  IT.  OR  TO  ASSKIATE  A  DATA  BLOCK  KITH  AN  ITEM  ALREADY 
ON  THE  CURRENT  NAP  DISPLAY. 


TIC  RTE  COMMAND  FORMAT  IS! 
INSERTdCLASS  =  <s*ticl>3,[LX  ■ 


<value>],  BLOCK  =  <valu»»i 


C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

caacccccxccccccccccccccccccccccccccccaxcccccccccccccacrcctcccccccccc 


FARAMETERS  ARE! 
CLASS  =  <s.ibol> 


LX  =  <value> 


BLXK  =  <valuf> 


OPTIONAL  PARAMETER  WHICH  SPECIFIES  TIC  SYMB0LD6Y 
CLASSIFICATION  X  TIC  ITEM  BEING  ADDED  TO  THE 
DISPLAY. 

XTIONAL  PARAMETER  WHICH  SPECIFIES  TIC  LOCATION 
VALUE  X  THE  ITEM  BEING  ADDED  10  THE  DISPLAY. 

IF  HOT  GIVEN.  DEFAULT  TO  TIC  CURRENT  LOCATION 
X  THE  CURSOR/LIGHT  PEN. 

REQUIRED  PARAMETER  WHICH  SPECIFIES  THE  DATA  BLOCK 


mCEDUK  NAME!  STOIC 


PROCEDURE  name:  ENTER 


ItUTOt.FTm 


ABSTRACT! 

THE  DHIL  'EATER'  COHHAND  IS  USED  TO  S1NUUTE  TTC  ANALYST 
ENTER  INS  DATA  INTO  A  PREVIOUSLY  tlSPLAYEI  FORA.  ONLY  THE  CONTENTS 
OF  TIC  DISPLAY  ARE  M0V1F1EB  -  THIS  COHMNI  HAS  NO  EFFECT  ON  THE 
DATABASE.  SUBSEQUENT  PRIMITIVE  IIRECTIVES  CONTROL  THE  DISPOSITION 
OF  TIC  DATA. 

TIC  RTE  COMMAND  FORMAT  IS! 

ENTER!  <fieldnaoe)  =  <nev  value>ti<fieldname>  =  <nev  value)!) I 
PARAMETERS  ARE! 

<fieldna»e>  -  THE  NAME  OF  THE  FIELD  RECEIVING  DATA 
<neu  value)  -  VALUE  TO  BE  ASSIGNED  TO  RECEIVING  FIELD 

FOR  THE  RTEi  THIS  COHHAND  HILL  DE  EXECUTED  AS  A  'HAIT*  TINE 


PROCEDURE  NAME!  ROUTE  ItROUTE.FTNtt 


abstract: 

The  DHIL  coeeand  ROUTE  is  used  to  insert  eessase  information 
into  the  alert  oueue  of  an  analyst. 

The  RTE  command  format  is! 

ROUTEILOGIN  =  <receivins  analyst).  MS6-ID  «  <fie1d  value). 

PRI  =  <f ield  value).  SUU  =  <field  value))) 

Reouired  parameters  are! 

LOGIN  —  the  losin  identifier  of  the  receiving  analyst 
MSG-ID  —  the  ns*-id-code  yhich  unieuely  identifies  a  oessame 
vithin  the  databas 
PRI  —  the  messaSe  priority 

SUBJ  —  brief  information  indicatins  the  subject/conlent  of 
the  aessade 


PWJCEMK  NAHE!  HARDCOPT 


UtftHCPT.FIWt 


abstract: 

THE  DHIL  'HARDCOPT'  COHHAND  IS  USED  TO  FORMT  MD  TRANSFER 
ALL  Of  PC  CURRENT  DISPLAY  TO  A  HARDCOPT  DEVICE. 

TTC  DTE  COHHAND  FORMT  IS! 

HARDCOPTI 

TIE  COMMAND  HILL  BE  ISSUED  AS  A  WIT  TI«  FOR  TIC  BENCHMARK 
EXERCISES. 


cttccccttcrcccaccttcttccccccccccccc^^ 

c 

c  PROCEDURE  NAME!  CMPRS  -  COMPRESS 

C 

C 

c  abstract: 

c 

C  CMPRS  Hill  cowrtss  m  buffer  bn  reeovin*  all  sracesi  tabs,  and 

C  nulls.  The  rceainder  of  the  lint  ur  to  thr  specified  nutber  of 
C  characters  is  raddtd  with  blanks. 

C 


C 


PROCEDURE  KMC!  IV  ANALYSIS 


abstract: 

K6-SCEX  IV-ANALYSIS! 

COMMENT!  ANALYSTS  SCANS  ALERT  OUEUE  FOR  INC0N1N6  ICSSA6ESI 
PERFORM  REVIEV-INPUTSI 

connekt:  amalyst  decides  if  the  message  retrieved  ts 

PERTINENT  AND  REOUIRfS  FURTHER  AMCTSISf 
SOMETIMES!. ?0.  .  H 
BEG-SOMEi 

PERFORM  STORE-NSSi 

comcht:  the  analyst  degins  gt  scanning  the  database  for 

INFO  ON  RECENT  ACTIVITY  VITKIN  THE  AREA  OF  INTEREST! 
PERFORM  FIND-AU -ACTIVITY! 
comment:  analyst  builds  a  mm>  OF  THE  AREA! 

PERFORM  DUILD-AREA-MAPi 

comment:  IN  ATTEMPTING  to  bound  the  area  of  search  TTC 
ANALYST  RETRIEVES  INFO  ON  THE  AIRCRAFT  SYSTEM 
REFERRED  TO  IN  THE  ICSSAGEI 
PERFORM  BOUND-AREA! 

CONtCNT!  UNDER  THE  ASSMPTIW  THAT  NO  IN-AIR  REFUELING 
HAS  TAMER  PLACE. THE  ANALYST  HILL  ATTEMPT  TO 
LOCATE  T!C  UNITS  ASSOCIATED  KITH  THIS  STSTEN. 

AND  PLOT  THESE  UNITS  ON  THE  MAPI 
PERFORM  FLOT-AUi 

comment:  the  analyst  queries  mac  for  all  HISSIONS 
SCHEDULED  IN  THIS  AREA! 

PERFORM  CHATTER-MAC! 

COMMENT:  OVERLAY  AIR  ROUTE  DATA  ON  NAP! 

PERFORM  PLOT-ar-ROUTES! 

PERFORM  STORE-MAP! 

COMMENT!  ANALYST  RETRIEVES  Ml  DISPLAYS  INDICATOR  LISTS! 
PERFORM  ERAM1IC-INDICATORS! 

COMMENT!  THE  ANALYST  HILL  ACTIVATE  APPROPRIATE  INDICATIVES! 
S0METHCSI.30.A.  )i 
BEG-SOMEI 

PERFORM  ACTIVATE-IMDJCATORSI 
END-SOME! 

COMMENT:  ANALYST  MUST  DETERMINE  IF  (AND  MCN1C0NFUCTS 
NIGHT  EXIST  FOR  FRIENDLY  RIGHT  ACTIVIH  IN 
THE  AREA  UNDER  SCRUNITYi 
PERFORM  COMPUTE -CONaiCI-TIMESI 
TNIMH30.M.A)! 

COMMENT!  ANALYST  PREPARES  DRTEF1N6  ON  ASSESSKNT  IN  ORDER 
TO  GAIN  CONCURRENCE  AND/OR  APPROVAL  OF  TIC  C 
ANALYTICAL  RESULTS! 

PERFORM  BRIEF-TEXT! 

COMMENT!  FOLLOVIMS  APPROVAL  of  THE  ASSESSMENT /BRIEFING 
.THE  ANALYST  IS  RESPONSIBLE  FOR  PREPARING  A 
HARMING  MESSAGE  NHEN  NECESSARY! 

S0NFIIPCS(.30».H 

BEG-SOME! 

PERFORM  PREP-VARNIHG-MSGI 
END-SOME! 

EMD-SCEM  IV-ANALTSIS. 
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cccccccccccccccccccccccccacctccccccactccccccc^^ 

c 

C  PROCEDURE  KWT.  REVIEIHUUTS  HttVlHP.ORAU 

c 

c  abstract: 

c 

C  BES-FUHC  REVIEV-ItfUTSi 

c  comment:  displat  number  mi  Kin  or  each  ejttrt  id  queue: 

C  ALERT! 

C  THlNKUO.JOiAli 

c  comment:  display  short  title  -  ml  queued  alerts; 

C  SCAM! 

C  TWNK(!0t30.A)f 

C  COHHEHT.  SELECTIVELY  DISPLAY  Ml  READ  A  MESSAGE  FROM 

C  THOSE  ROUTE!  THROUGH  TIC  ALERT  OUEUEI 

C  RETRIEVE  (A001.lt  AOOltl  Ed  •*•)! 

C  THIHlUIOtPOiAI) 

C  PAGE! 

C  THINK(30.?O.A)i 

C  EHD-FUHC  REVIE1HHUTS. 

C 

c 

cccacacaccccactmcaxcttcccOTcccccccaaccccaxccccaxcacccaccra 


PROCEDURE  HAHE:  ST0RE-HS6 


ttSTONSG.FTttt 


abstract: 


BEG-FUHC  STORE -HSGI 

comment:  store  TIC  INPUT  MESSAGE  M  A  TEKURARY 
PERSONAL  FILE  FIX  LATER  USE! 

store; 

EHD-FUHC  STORE -HSG. 


c 

ccccccaccccctxccccccaccaxaxcccacaccaLccccccaccaxccccaxcccccra 
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PROCEDURE  NAHE!  FIND-ALL-ACTIV1TY 


IIFNDACT  .ORAtt 


C 

c 
c 

c  abstract: 

C  BE6-FUNC  FIND-ALL-ACTIVITYI 

c  cohhent:  ouert  the  ewnt  file  for  recent  activity 

C  OCCURRING  WITHIN  TIC  SPECIFIED  COUNTRY! 

C  0UERY<BO01.1.B001t23  ES  ‘I*  AND  BOOltll  EO  Til 

c  cohheht:  analyst  retrieves  and  scans  EACH  RECORD  FOUND! 

C  THINXt30i304iA)i 

C  PAGE! 

C  THINK! 30 1 300  >  A) » 

C  END-FUNC  FIHD-ALL-ACT1VITY. 

e- 

c 


cccccccccccccccacccccccccctcaccccccccccccccccarccccccccccccccccccccca 

c 

C  PROCEDURE  NANEI  BUILD- AREA- HAP  ttlBLDHAP.FTNBU 

C 

C 

c  abstract: 

C  BEG-FUNC  BUILD-ARE A-HAPi 

C  COHHENT:  ANALYST  BUILDS  A  HAP  OF  TIC  AREA  REFERRED  TO  IN 

C  THE  PCSSAGEt 

C  HAFOAT  =  .LON  =  )i 

C  THINK ( 2. St  )! 

C  END-FUNC  BUILD -AREA-NAP. 

C 

C 

cccccccccccccccccccccccccccaxccaxamccccamaxcccccccamccccccccc 


c 

c  PROCEDURE  NAHEI  BOUND-AREA  tlBNDARE.ORAtt 

C 

C 

c  abstract: 

C  BEG-FUNC  BOUND-AREA! 

C  REIRIEVE(DO01.2tDO0Hl  EO  'FIGHTER'  AND  D001D2  EO  '!’)! 

C  THINKI10.29.AII 

C  END-FUNC  BOUND-AREA. 

C 

c 

ccccccccacccccccccccaccccccccccamcccccccccacaccccccccccccccccccca 


psoatus  mame:  hot-mi 


UPLYAOB.ORAO 


abstract: 

BEG-FUNC  PLOT-AOli 

coment:  ANALYST  SEAROCS  TOR  UNITS  HITHIN  T*  MX.  RANGE 
OF  TTC  SIGHTING  OF  TIC  AIRCRAFT  HHICH  ARE  KNOW 
TO  HAVE  THIS  STSTEH  TYPE) 

CSEARCHiCOOl.liCOOltUIA  EO  TIGHTER'  MO 

COOlilUB  ES  D001I2.LAT  =  'i'llON  =  Ti 
RANGE  =  IOOOKMIi  (WORN  NOT-IDENTIFIEJi 
BEG- SEARCH I 
THINK(2»5f  )i 

cghheht:  analyst  scans  each  unit  record  found  and  plots 

ONTO  MPi 

REVIEW 

THlNK(Mtl2t>A)i 

PAGE) 

THINXIJOfiOiAK 

PLOT!  i CLASS  =  COOltlt  )l 

END-SEARCH) 

END-FUNC  PLOT-AOB. 


CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC^^ 


PROCEDURE  NAME;  CHATTER-MC  MICHTMC.FTNttl 


abstract: 

BEG-FUNC  CHATTER-MC) 

INSERT (i (BLOCK  =  'ANT  MSSIOKS  IN  THIS  AREAYMi 
THINKTSrlO.)) 

CHATTER  MC-ROUTE-TWEAT-ASSESS! 

cohhent:  the  analyst  waits  for  mc  to  respond  with 

HISSION-IDs  FOR  ALL  OPERATIONS  IN  THE  AREA) 
THINK(300)AMi» 

SCAN) 

THINK(SilOfl) 

DISPLAY) 

THINK<20tJ0.» 

END-FUNC  CHATTER-MC. 


PROCEDURE  NAKE!  PLOT -fll -ROUTES 


iw.rert.nwi 


abstract: 

KS-fUNC  PLOT-fLT-ROUTES) 

COMMENT!  THE  NW.TST  HILL  HE  QUEST  ALL  MISSION  INFORMATION 
TO  OLCRLAY  ON  PREVIOUSLT  CONSTRUCTED  NN>, 

BASE)  ON  THE  INFO.  MAC  SENT) 

SOHETIICS! .30.A.L00P  =  3)1 
KS-SONEi 

RETRI£K(H00I.1.H001I2  EO  MM! 

THINK! 120.300.*)! 

COMMENT!  PLOT  TtC  DEPARTURE  POINT  NO  T*6  EACH  ROUTE 
KITH  ITS  MISSION-ID. 

PLOT! .  CLASS  =  'MSN'. If 
THINKfS.10.  )> 

INSERT!  .  .BLOCK  *  H001I2H 
comment:  the  analyst  requests  NO  PLOTS  ALL 
SESFCNT  INFORMATION) 

SEARCH!  1002. 1.1002)70  ES  HOOH21I 
BES-SEARCHI 
THIMCFS.lOi  )i 
REVIEW 

THINXdO.JO.  )) 

SES!  .  .TOP  LAT  >  I002I7.T0P  LON  •  I00207A) 
ENO-SEANCHI 
END- SDK! 

EHD-flBC  PLOT-fLT-ROUTES. 


PROCEDURE  NAME:  EXAMINE-INDICATORS  ItEXNlNB.ORAn 
ABSTRACT! 

BEG-FUNC  EXAMINE-INDICATORS) 

COMMENT!  THE  ANALTST  REOUESTS  ALL  MILITARY  INDICATORS 
FOR  TtC  COUNTRY  OISERVEDI 

OUERVIFOSl.l.FOODl  EQ  COOIMO  AND  FOOII21  EO  'NIl*)f 

THlNF.dO. 15. )t 

PACE. 

THINK! 10.13.)! 

END-FUNC  ET AMINE-INDICATORS. 


PROCENJFE  mi:  ACT1VATE-IN1I1CAT0RS 


ISACTIND.ORAM 


cccccca 
c 
c 
c 
c 

c  abstract: 
c 

C  BES-FUNC  ACT1VATE-IND1CAT0RS! 

c  cohheht:  update  the  indicator  .tatusi 

C  H0DIFY(F001t24  «  'A'li 

c  cohheht:  the  analyst  hakes  twrucopr  for  later  referehcesi 

C  HARDCOPY! 

C  THINK<5il0i>! 

C  00-FUNC  ACTIVATE-INDICATORS. 

c 

c 


ccccccccccccccccccccccccccccccccccctxcccccc^^ 

c 

C  PROCEDURE  NAHE!  COHPUTE-CONFLICT-TI*  »MCHPT1H.FTNW 

C 

c  abstract: 

c 
c 
c 


i  i 

C 

C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 


PROCEDURE  nape:  BRIEF-TEXT  tXBRFTXT .FTNtt 


abstract: 

BES-FUNC  BRIEF-TEXT! 

cohheht:  analyst  displays  fuuy  constructed 

HAP  AND  DISCUSSES  TIC  ASSESSMENT! 

RECALL! 

TH1NM60*123iAI! 

CONCNT!  analyst  displays  tic  hessage  that 
LED  TO  THIS  CONCLUSION! 

RECALL! 

THINKf 60i125iA1) 

END-fUNC  BRIEF-TEXT. 


cccccaccacccccccaccccctmccccccctxc^ 

c 

C  PROCEDLK  NAME:  PREP-WARNING-NSS  UPRWhSG.FTNW 


abstract: 

BEG-FUNC  PREP-NARNING-nSSS 
cowot:  analyst  displays  message  fokmt  and  enters 

APPROPRIATE  DATA! 

FOR II  AOOl.li 
THINKIS.IO.  )t 

ENT£R(A001»t  =  'ISA00IB71  -  'IS 
AOOIMO  =  'UNUSUAL  INDICATORS 
A001I200  =  'NESSAGE  TEXT  -  DETAILS  OF  EVALUATION'  >i 
TH1NM30.40.  )i 

cowot:  this  warning  message  mill  be  added  to  the  database 

MESSAGE  FILE.  THE  ANALYST  WILL  HAKE  A  PERSONAL  COPT 
THEN  ROUTE  THE  MESSAGE  TO  THE  SUPERVISOR'S  ALERT 
QUEUE! 

ADDON  AOOl.li 
HARDCOPY! 

THINKI5.10.  )! 

ROUTE  ( LOGIN  =  'DIV-CHIEFSHSS-ID  =  AOOU1.PR1  =  'IS 
SUBJ  =  'UNUSUAL  INDICATOR')! 

END-FUNC  PREP-WARNING-HS6. 


cccccccccccccccccccccccccccacccaccccctxtmccccacccccccccccccccaccccc 


ccccccccccccccccccccccccccccccccccccccaccaxccccccccccccccacccccccccca 

c 

c  PROCEDURE  NAHEI  ALERT 


^.LM  will  sltulaLt  an  nidlnl  VistlayinS  nutbtry  and  lyp*s~ 
cf  atssaws  on  th*  alert  oueue.  The  actual  aesuNrs  art  not  relevant. 


cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccaxccccc 


PROCEDURE  NAME!  THWC 


ccctxctc 
c 
c 
c 
c 

c  abstract: 

c 

C  THINK  simulates  an  analyst  eullinj  over  a  decision.  Stout*  of 

C  this.  tlie  result  is  divided  by  the  alert  sUtus.  Obviously.  the 
C  analyst  uill  think  less  tit*  in  *  crisis  or  uar  situation. 

C 
C 

c  input: 

C 
C 
C 
C 

cccccccccccccccctcccccccccc(^(xcccaccimracu:ccccccctxcccccccccicccccc 


MIN  -  1  HUGER i  Hinieuo  eeacetioe  vail 
MAX  -  INTEGER!  Kaxiou*  uait  at  any  tie* 

ALERT  -  INTEGER!  Alert  status  (1>2>3) 


C  PROCEDURE  NAME!  SCAN 

C 

c 

c  abstract: 

c 

C  SCAN  5i»ulates  an  analyst  scanninj  throuJh  the  list  of  alert 

C  aessaaes. 

C 

C 

ccccccccccccccccccccccccccccccccccccccccccccccccccccacacccccccccccccccc 


cccccccccccacccaccccccccccccccanxccaaccccccaccccccccaxccccccccccc 

c 

C  PROCEDURE  NAME:  STORE 

C 

c 

c  abstract: 

c 

C  THE  DHIl  'STORE1  CONWND  IS  USED  TO  SAVE  TIE  CURRENT  SCREEN 

C  DISPLAY  (NAP/RECORD)  IN  A  TEMPORARY  FILE  FOR  FAST  RECALL  AT  A  LATER 
C  TINE.  ONLY  THREE  'RECORDS'  CAN  BE  STORED  AT  ANT  TINE.  AND  THEY  ARE 

C  ACCESSED  ON  A  LAST-IN  FIRST-OUT  BASIS  VIA  THE  'RECALL'  CONNAXD. 

C 

C 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCttCCCCCCCCCCCCCCCCCCCC 


C-2 1 


PROCEDURE  NAME:  FLO! 


im.QT.FTW* 


c 
c 
c 

C  TIC  DHIL  'PLOT*  COMMAND  IS  USED  TO  DISPLAY  DBMS  ITEMS  ONTO  A 

C  PREVIOUSLY  GENERATED  MAP  BACKGROUND. 

C 

C  THE  RTE  COMMAND  FORMAT  IS! 

C  PLOT(C<ustrvitw>f<fieldnJM>  <rtlw>  <fitldvilue>  [<IoMP> 

C  <fieldnate>  <relof>  <fi<ldvilue»] .CLASS  -  <s«bol>i 

C  [BLOCK  I  NOBLOCK])  i 

C 

C  PARAMETERS  ARE! 

C  <uservien>.<f ieldfl3«e>. . .<f ifldvaluf>  -  OPTIONAL  SELECTION  LIST 

C  WHICH  UHEN  SPECIFIED  CAUSES  A  DATABASE  ACCESS  FOR  Ml  RECORDS 

C  THAT  MEET  THE  CRITERIA  TO  BE  PLOTTED  ONTO  TIE  MAP. 

C  IF  NOT  SPECIFIED.  PLOT  THE  INFO.  ASSOCIATED  WITH  THE  RECORD 

C  CURRENTLY  BEING  DISPLAYED. 

C  CLASS  -  REQUIRED  PARAMETER  WICH  INDICATES  THE  CLASSIFICATION  OF 
C  SYMBOLIC  DATA  TO  BE  PRESENTED  ON  THE 

C  BLOCK  I  NO  BLOCK  -  OPTIONAL  PARAMETER  IHICH  SPECIFIES  WETHER  A  ‘DATA 

C  BLOCK/TAG'  IS  TO  BE  APPENDED  TO  EACH  SYMBOL  GENERATED  FOR 

C  DISPLAY.  BLOCK  IS  TIC  DEFAULT. 

C 

c  note:  this  is  the  only  DHIL  command  that  hill  EITHER  BE  EXECUTED  AS 
C  A  “WAIT"  TINE  (UHEN  ISSUED  WITH  HO  SELECTION  LIST),  OR  MAKE  A 

C  DATABASE  ACCESS  (UHEN  ISSUED  U1TH  A  SELECTION  LIST). 

C 

c  iiimtiiittimttiiitiiimmtimiittimiiiititmttnimitmn 

c  ummmmimmummmmmmtimmtmmmmmmt 

C  UltTHIS  'PLOT'  FUNCTION  SHOULD  ONLY  BE  CALLED  BY  FUNCTIONS  WICHUtt 

C  MMARE  ISSUING  A  DHIL  PLOT  COMMAND  WITHOUT  A  ERECTION  LISTIIMUU* 

c  itttmtmtummmumtmtmimutmtmmmmmmttn 

c  ttmottttummmmmmumuusmmmmmmumnm 

c 
c 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCOX 
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ccccccccccccccccccccccccccccccccccccrcccccccccccccccccccccccccccctxcccccc 

c 

PROCEDURE  NAME:  NOI-IDENTIPIED  IStNOTID.FTNtU 


ABSTRACT: 

BEG-FUNC  NQT-IDENTIFIEDi 

COMMENT:  THE  ANALYST  COWOT  IDENTIFT  THE  SOURCE  Of  THIS 
AIRCRAFT  BASED  ON  CURRENT  INFO.,  SO  DECIKS  TO 
NOTIFY  THE  DIV-CHIEF/SUPERVISOR. 

RECALL) 

THINKIS.IO,  H 

ROUTEtLOGIN  =  'DIV-CH1EF\HSC-ID  =  ADOIll.PRI  =  T, 

SUBJ  =  •INSUFICIENT  INFO.  TO  IB  -  PLEASE  ADVISE’  H 
END-FUHC  HOT-IDEHT1FUD. 


ccccccccccccccccccccccccccccccccc^ 

c 

C  PROCEDURE  NAMES  INSERT  MINSERT.FTNU 

C 

C 

c  abstract: 

c 

C  THE  DHIL  ‘INSERT'  COHHAND  IS  USED  TO  ADD  A  HEN  ITEM  TO  TIC 

C  SPECIFIED  LOCATION  ON  TIC  CURRENT  HAP  DISPLAT  VITH  A  DATA  BLOCK 

C  APPENDED  TO  IT.  OR  TO  ASSOCIATE  A  DATA  BLOCK  WITH  AN  ITEM  ALREADY 

C  ON  THE  CURRENT  HAP  DISPLAY. 

C 

C  THE  RTE  COHHAND  FORHAT  IS! 

C  INSERT! [CLASS  =  <sytbol>}iCLOC  *  <value)]> BLOCK  *  <value»l 
C 

C  PARAMETERS  ARE! 

C  CLASS  =  <5sibol>  -  OPTIONAL  PARAICTER  WHICH  SPECIFIES  THE  SYHBOLOOY 

C  CLASSIFICATION  OF  TFC  ITEM  BEING  ADDED  TO  THE 

C  DISPLAY. 

C  LOC  =  <vjluc>  -  OPTIONAL  PARAMETER  WHICH  SPECIFIES  THE  LOCATION 
C  VALUE  OF  THE  ITEH  BEING  ADDED  TO  TIC  DISPLAY. 

C  IF  NOT  6IVEN1  DEFAULT  TO  THE  CURRENT  LOCATION 

C  OF  THE  CURSOR/LIGHT  PEN. 

C  BLOCK  =  <value>  -  REQUIRED  PAR  ASTER  WHICH  SPECIFIES  TIC  DATA  BLOCX 

C 

C 

CCCCCCCCCttCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCa 


CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 

c 

c  PROCEDURE  NAME:  CHATTER  ttCHTTER.FTNtt 

c 

c 

c  abstract: 

c 

C  THE  DHIL  'CHATTER'  COHHAND  IS  USED  TO  SEND  A  COPT  OF  THE 

C  CURRENT  TERMINAL  DISPLAY  TO  ANOTHER  ANALYST  THROUGH  THE  ALERT 

C  QUEUE. 

C 

C  THE  RTE  COHHAND  FORHAT  IS! 

C  CHATTER  <receivind  LOGIN  identifier)  [.(receiving  LOGIN  identifier))! 

C 

C 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCItCCCCCCCCCCCCCCCCC 


PROCEDURE  NAME!  DISPLAY 


tiomr.FiNU 


c 

C 
C 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 

CCCCCCCCCCKCCCCCCCCCCCCCCCmCCCCCCCCCCCCttCKCCttCCCCCCCCCCCCCCCCCCCCCC 


abstract: 

tic  wu.  'Disfur  comm  is  used  to  display  an  alert 

QUEUE  ENTRY  TO  TTE  TERMINAL.  THE  RTE  FORM!  IS! 

MSPLAY  Kalert  r>K INTO  FORM  <uverview>ll 

BOTH  ARE  OPTIONAL  FARAICTERS.  WHERE! 

<alert  nu*b«r>  -  THE  NUMBER  OF  THE  ALERT  QUEUE  ENTRY  TO  K 
DISPLAYED.  IF  NOT  SPECIFIED.  DEFAULT  TO 
HIGHEST  PRIORITY  ALERT  OUEUE  ENTRY. 

INTO  FORM  <userview>  -  PARAMETER  USED  BY  TIE  UPDATE  SCENARIO 
TO  DISPLAY  AM  ALERT  QUEUE  ENTRY  INTO  THE 
SPECIFIED  <userviey>  FORMAT. 


ccccccccccaccccucccaccccccccccccccccccccccccccccccccccccccccamc rate 
c 

PROCEDURE  NAME!  CMPRS  -  COMPRESS 


ABSTRACT! 


CMPRS  uill  co*pr«ss  am  buffer  by  reeovinS  all  spates,  tabs,  and 
nulls.  The  reminder  of  the  line  up  to  the  specified  nueber  of 
characters  is  padded  uith  blanks. 


ccccccccccacccccccccccccccccccccccccccccccccccccccccccccccccccccccccaxc 

c 

C  PROCEDURE  NAME!  EVEN 

c 

c 

c  ABSTRACT! 

C 

C  EVEN  will  add  one  to  an  odd  inteser.  and  isnore  an  even  inteder. 

C  This  faction  is  necessary  for  the  ADABAS-H  search  buffer  lenjth. 

C  which  oust  be  an  even  nueber. 

C 

C 

cccccccccccccccccccccccaccccccccccccccacccccccccccccccccccarcccccccca 


„  -  .  •  > 
■ .'A 


PMCBIK  mac:  SJS 


tiae.mm 


THE  MIL  'SE6‘  CONNAND  IS  USES  TO  UTAH  A  LINE  SE6CNT 
BETWEEN  TUO  POINTS  ON  A  DISPLAY. 

THE  RTl  COWAND  FORMAT  IS! 

XKtnw-LAT  *  <Yro*-liMUidf>t  FIOM-LON  •  <Tn»-l<irtiUid»>]« 
TO-LAT  *  <lo-ljtiUxW>i  TO-LON  -  <lo-lonNiludf»( 

PARAMETERS  ARE'. 

FROH-LAT  AND  FROH-LON  ARE  OPTIONAL  PARAMETERS  MUCH  SPECIFY 
THE  STARTING  POINT  OF  THE  SEGCNT  TO  K  DRAUN.  IF  NOT  SPECIFIED. 
DEFAULT  TO  TC  CURRENT  POSITION  OF  TIC  CURSORAISHT  PEN. 

TO-LAT  AND  TO-LON  ARE  REQUIRED  PARAMETERS  IM1CM  SPECIFY  THE 
ENDING  POINT  OF  THE  SEGMENT  TO  BE  DRAUN. 


PROCEDURE  NAME!  HARDCOPY 


MHRDCPY.FTNtt 


THE  mil  ' HARDCOPY'  COMMAND  IS  USED  TO  FORMAT  AND  TRANSFER 
ALL  OF  DC  CURRENT  DISPLAT  TO  A  HARDCOPY  DEVICE. 

THE  RTE  COMMAND  FORMAT  IS! 

HARDCOPY! 

THE  COMMAND  MILL  BE  ISSUED  AS  A  WAIT  TIC  FOR  TC  BENCHMARK 
EXERCISES. 


Rand 
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ccccccccccaccccccctaxccccccccaxccccccccccccccccccccccccccaccccccccccc 

c 

c  PROCEDURE  MACS  RECALL  URECALL.FTNtt 


TC  DHIL  'RECALL'  COMMAND  IS  USED  TO  ACCESS  A  MAP/RECORD 
WHICH  HAS  SEEN  STOREd  IN  A  TEMFORART  FILE. 


ccacccaccccccccccccccccccccacrccctcccctcccccccccccccccaacccttccccca 
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PROCEDURE  NAMES  FORM 


mform.fib* 


c 
c 
c 

c  asstract: 

c 

t  The  FORM  cotaand  is  used  to  disrlav  the  twliti 

C  Foraat  For  l he  seeciFied  userview. 

C 

C  The  RTE  rotund  forut  it! 
t  FORM  <userview)i 

C  This  cotund  is  used  to  display  a  Fort  which  will  than 
C  have  inForaation  ENTERed  into  it  be  the  analyst  (a  seeuenct 
C  oF  stars  used  to  add  a  record  to  the  database).  For  testind 

C  purposes  this  cotaand  will  be  executed  as  a  BAIT  tit*. 

C 

C 


C  PROCEDURE  NAME!  ENTER  tIENTER.FTNtt 

C 

C 

c  abstract: 

c 

C  THE  DHIl  'ENTER'  COMMAND  IS  USD  TO  SIMULATE  THE  ANALYST 

C  ENTERING  DATA  INTO  A  PREVIOUSLY  DISPLAYED  FORM.  ONLY  TIC  CONTENTS 

C  OF  TK  DISPLAY  ARE  MODIFIED  -  THIS  COMMAND  HAS  NO  EFFECT  ON  TK 
C  DATABASE.  SUBSEOUENT  PRIMITIVE  DIRECTIVES  CONTROL  THE  DISPOSITION 
C  OF  TIC  DATA. 

C 

C  THE  RTE  COMMAND  FORMAT  IS! 

C  ENTERKFieldnate>  «  <new  value>[i<Fieldnate>  =  <new  value)])! 

C 

C  PARAMETERS  ARE! 

C  <Fieldna«e>  -  THE  NAME  OF  TIC  FIELD  RECEIVING  DATA 

C  <new  value)  -  VALUE  TO  BE  ASSIGNED  TO  RECEIVING  FIELD 

C 
C 
C 

c 

CCCCCCCC 


FOR  THE  RTE.  THIS  COMMAND  Hill  BE  EXECUTES  AS  A  'IIA1T'  TIIC 


»»» 


PROCEDURE  NAHE!  COLLECTION-COORDINATION 


mCOLCOR.ORAlU 


c 
c 
c 

C  ABSTRACT 
C 
C 
C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


BEG-SCEN  COLLECTION-COORDINATION! 

COflHENT:  SCAN  ALERT  QUEUE  TO  SEE  WHAT'S  NEEDED! 

PERFOKH  GET-COLL-INPUT! 

cowient:  the  analtst  hill  search  the  database  for  au. 
HIGHEST  PRIORITY  REQUESTS'  TIC  ANALYST  LOOKS 
FOR  ANY  CORRELATIONS  WHICH  RIGHT  ALLOW  THE 
REQUESTS  TO  BE  PROCESSED  HORE  EFFICIENTLY! 
COMMENT:  THE  ANALYST  PROCEEDS  BY  SEARCHING  THE  DATABASE 
FOR  ALL  REQUESTS  THAT  FIT  THE  ’CORRELATION*. 
THEN  PROCESSES  THESE  INDIVIDUALLY! 

PEKFORH  EXTRACT-AND-PRQCESS-RE QUIRE HE NTS! 

END-SCEN  COLLECTION-COORDINATION. 


C 

C  PROCEDURE  NAME:  GET-COLL-INPUT  ttGETCI.FTNtt 

C 

c 

c  abstract: 

c 

C  BEGFUNC  GET-COLL-INPUTI 

C  comment:  GET  SORE  DETAIL  ON  WHAT’S  IN  THE  ALERT  QUEUE! 

C  ALERT! 

C  THINKI2.5.)! 

C  SCAN! 

C  THINK!  10.30.AI! 

C  COMMENT :  DISPLAY  HIGHEST  PRIORITY  ALERT! 

C  DISPLAY! 

C  THINKU0.30.A)! 

C  ENU-FUNC  GET-COLL-INPUT. 

C 

c 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 


i 


BEG-fUNC  EXTRACT -AHD-FROCESS -RE  QUIREHEXTSI 
COHHENT:  GET  ALL  HIGHEST  PRIORITY  REQUESTS! 

OUERTI 6001.1 1 BOOKS  EO  'i'll 

THINK!  10.40.!  I 

PAGE! 

THINMIO.AO.K 

Conner .  tic  HNHLYSt  NIU.  THEN  SELECT  TIC  AREA  REOUIRIM 
THE  HOST  COVERAGE  AND  REVIEH  AU.  RECCE  OPERATIONS 
SCHEDULE!!  FOR  THIS  AREA  TO  DETERMIME  TIC  RESOURCES 
1HHED1ATELT  AVAILABLE! 

PERFORN  REVIEN-RECCEI 

CONMEHT:  THE  analyst  HILL  ITCH  REVIEH  All  COLLECTION 
REQUESTS  FOR  THIS  MCA! 

SEARCWGOOl.l.GOOlMJ  EG  JOOltlM 
REG-SEARCHi 
THINK12.5.K 

COHHENT !  TIC  ANALYST  HILL  EXAMINE  AND  PROCESS  EACH 
REQUESTI 

REVIEH! 

TH!NK(30.40.)I 

COHHENT.  THE  ANALTST  RETRIEVES  TIE  AUTHORIZATION 
FORH  FOR  THIS  REOUESTI 
PERFORN  6ET-CQU.-AUTH0R1ZAT  IONS 
COHHENT:  SOME  REQUIREMENTS  NAT  ALREADY  K  COVERED 

bt  previous  requests; 

SOHETIHESMOi.H 

BEG'SOIEi 

PERFORN  REJECT-REQUEST; 

END-SOHEt 

COHHENT:  WHEN  A  REOUEST  HILL  BE  FIllEti  TIE  COLLECTION 
COORDINATOR  HIU  DETERMINE  NHETHER  FLTIN6 
MISSIONS  ARE  CAPABLE  OF  FILLING  THE  REOUEST. 

IF  ’EXTERNAL'  SOURCES  HUST  IE  CALLED  UPON. 

THE  ANALTST  HUST  ALERT  TIE  SUPERVISOR! 

SOHf TINES! .5.» )» 

BEG-SOHEi 

FLRfORH  REROUTE-REOUEST! 

END-SOHEt 

COHHENT:  ONE  OF  T*  CURRENTLT  SCHEDULED  RECCE  OPERATIONS 
nAY  IE  CAPABLE  OF  HANDLING  THIS  REOUEST) 
SOMETIMES! .30..). 

BEG-SOHEI 

N0P|FT!G00K1II  =  'I'.GOOIM*  *  'CAN  THIS  MISSION 
COVER  THIS  REOUEST. TOOT’ I I 

THINKIS.10.il 
CHATTER  MV-CH1EFI 

end-some; 

COMMENT :  SOHE  REQUESTS  HILL  REQUIRE  THE  SCHEDULING  OF 
A  NEH  mission; 

SOHETIHES!.SSii)i 

BEG-SOHEi 

HODiFY(GOOK124  *  'CAN  THIS  BE  SOEDULEDT'I! 

THINK13.10.il 

CHAITEB  DIV-CHIEFi 

end-some; 

END-SEARCH'. 

END-FUNC  EXTRACI-AND-PROCESS-REOUIREHENTS. 


*  -  '  •  J  *. 
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m 


»  m> >  * 
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PROCEDURE  NNC:  REVIEIHfECCE 


MREVRCE.ORAM 


c 
c 
c 

c  abstract: 

C  IEG-FUNC  REVIEU-RECCE! 

C  cwvofi;  analyst  klvicns  mu  mhui 

c  query(jmi.i.jooih  cs  •»•» 

C  THINr.U0.30.M 

C  PAGES 

C  THINr(10.30.)i 

c  cowon:  analyst  requests  mo.  on  all  recce  rissions 

C  SCHEDULED  IN  THE  AREAS 

C  SEMCHIH001.1.H001II  E0  ‘REC1  AND  H001I7  EO  JOOIIUI 

C  BEG-SEARCH! 

C  TNINK<2.5.)f 

C  REVIEW! 

C  THINK! 120. 300. A) i 

C  END- SEARCH 

C  END-FUNC  REVIEV-RECCE. 

C 

acccttcccccccccacccctccccccaacccccccccccctxcctccccccccccccccccccccccc 


c 

c  PROCEDURE  NAME:  GET -COLL-AUTHOR! ZAT10N  UGETCA.ORAU 

C 

C 

c  abstract: 

c 

c  EE6-FUNC  GET -COLL-AUTHORIZAT  ION! 

c  CONHENT:  THE  ANALYST  WIU.  FIU  OUT  ALL  APPROPRIATE 

c  INFO.  ON  THIS  FORK  NNENEWt  A  COLLECTION 

C  REQUEST  IS  PROCESSED  I  DISAPPROVED/ 

C  APPROVED.  REAS0N/SCHEDUUN6  INFO..  ETC. >S 

C  RETRIEVETS001.2.  G001S3  EO  G001I3)! 

C  THlNK(2»5.)i 

C  END-FUNC  SET-COLL-AUTHORHATION. 

C 

C 


C 

C  PROCEDURE  HAKE!  REJECT-REQUEST  IIREJECT.ORAU 

C 

c 

c  abstract: 

c 

C  BEG-FUNC  REJECT-REQUEST  i 

c  cokkent:  not  in  requesting  analyst  that  the  worhation 

C  DESIRED  HAS  ALREADY  BEEN  REQUESTED  OR  FILLED! 

C  H0DIFYTG001I12S  =  'O'.  G00H124  =  'YOUR  IlfO.  IS  ON  THE 

C  NAT'H 

C  THINK(3. 10.11 

C  CHATTER  ANALYST! 

C  END-FUNC  REJECT-REQUEST. 

C 


ccccccccccaaacccaccctttccccaccccccccccaxtcasaccaxaccaxtxuxai 

c 

C  PROCEDURE  NMt:  ALERT 

C 

c 

c  abstract: 

c 

C  ALERT  mil  sioulate  an  analyst  disrlayins  nuebers  and  tyres 

C  of  aessases  on  the  alert  aueue.  The  actual  oessades  art  not  relevant. 


C 


C 


ncttctxcccccccttcaccttcccccccccaxtcacccaxnxaxccaxcaxnxcccccnxc 


ccaxracccaccacccccaxcacaaccccccccmicaxacacccaxccaccccccccix 

c 

C  PROCEDURE  hake:  think 

c 

c 

c  abstract: 

c 

C  THINK  simulates  an  analyst  aull ins  over  a  decision.  Because  of 

C  this,  the  result  is  divided  by  the  alert  status.  Obviously,  the 
C  analyst  vill  think  less  tioe  in  a  crisis  or  var  situation. 

C 

C 

C  INPUT!  KIN  -  INTEGER!  Hiniauo  eeacetiae  aait 

C  MAX  -  INTEGER.  Naxiauo  wait  at  any  tioe 

C  ALERT  '  INTEGER!  Alert  status  I1.2.J) 

C 

C 

craccccccccccccoxcaccacccixcaxccaaxamaxicaxamcactaxaicc 


C-31 


menus  me:  sew 


c 

c 

t 

t 

c 

c 

t 

c 


aistmct: 

SCW  siMiUWs  m  mint  temint  UiratWi  Uw  liit  of  oltrt 
wuM. 


C 

C  PROCEDURE  WUC!  DISPLAT  HDISPLT.FTW* 

C 

c 

c  abstract: 

c 

C  TIC  MIL  'DISPLAY'  COWARD  IS  USED  TO  DISPLAY  AN  ALERT 

C  QUEUE  ENTRY  TO  THE  TERHINAL.  DC  RTE  FORHAT  IS! 

C 

C  DISPLAY  Kolort  m*t*r>][lMT0  FORM  <w*rview>3l 

C 

C  BOTH  ME  OPTIONAL  PMAICTERSi  UHERE! 

C  <jl»rt  nuiber>  -  TIC  NUMBER  OF  THE  ALERT  QUEUE  ENTRY  TO  K 
C  DISPLAYED.  IF  NOT  SPECIFIED.  DEFAULT  TO 

C  HIGHEST  PRIORITY  ALERT  QUEUE  ENTRY. 

C  INTO  FORM  <userviw>  -  PARAMETER  USED  DY  THE  UPDATE  SCENARIO 
C  TO  DISPLAY  AM  ALERT  QUEUE  ENTRY  INTO  THE 

C  SPECIFIO  <us*rviw>  FORMAT. 

C 

C 

C 

CCCCCCCCCCCCCCCCCCCCCCCCCCC^ 


C 

c 

c 

c 

c 

c 

c 

c 

c 

C 


PROCEDURE  NAME!  CHATTER  IICKTTER.FTNO 


abstract: 

TIC  MIL  'CHATTER'  COMMAND  IS  USED  TO  SEND  A  COPY  OF  TIC 
CURRENT  TERMINAL  DISPLAY  TO  ANOTHER  ANALYST  THROUGH  THE  ALERT 
QUEUE. 


TIC  RTE  COMMAND  FORMAT  IS', 

CHATTER  <f*ceivinS  LOGIR  i<fcnt,fi*r>  (iCrtctivin*  LOGIN  i<tentifi»r>3( 


mCOLDEL.ORAtt* 


PROCEDURE  NMC:  COLLECTION-COORDINATION 
MH/0EL£TE« 


abstract: 

BEG-SCEN  COLLECTION-COORDINATION! 

cowcht:  scan  MINT  Wit  TO  SEE  UHAT'S  needed! 

PERFORN  GET-COU.-INPUT! 

comment:  ne  analyst  will  search  the  database  for  all 
HIGHEST  PRIORITY  REQUESTS.  TTC  ANALYST  LOOKS 
FOR  ANY  CORRELATIONS  WHICH  NIGHT  ALLOW  THE 
REQUESTS  TO  BE  FROCESSEO  WORE  EFFICIENTLY! 
comment:  THE  AN&YST  PROCEEDS  BY  SEARCHING  DC  DATABASE 
FOR  Mi  REQUESTS  THAT  FIT  TIC  ’CORRELATION'. 
THEN  PROCESSES  THESE  INDIVIDUALLY! 

PERFORN  EXTRACT-PROCESS-AND- DELETE -REOUIREHENTSI 
END-SCEN  COLLECTION-COORDINATION. 


PROCEDURE  MMC!  EXTRACT-PROCESS -AND- BCIETE-*£W1I€1€XT1 
UFXTD&.ORAU 


abstract: 

BEG-FUNC  EXTRACT-PROCESS-NO-DELETE-REWIREICNTS! 
conhent:  GET  ALL  highest  priority  requests* 
0UERY(G001.1.6W1M  EG  T)i 
THINKUO.AO.)! 

PAGE! 

THIHXUO.M*)! 

comment:  the  analyst  via  net  select  tic  area  rewiring 
nc  HOST  coverage  and  reviem  all  recce  operations 
SCHEDULED  FOR  THIS  AREA  TO  DETERNIIC  TIC  RESOURCES 
INNEDIATELY  AVAILASLEi 
FERFORN  REVIEIHIECCEi 

COHHENT:  THE  ANALYST  ilia  THEN  REVIEH  ALL  COLLECTION 
REQUESTS  FOR  THIS  AREA! 

SEARCHIGOOl • 1 *0041(43  EO  JOOIIIH 
BE6-SEARCH* 

THINK(2.5.)i 

comment:  nc  analyst  via  examiic  and  process  each 
request; 

REVIEHi 

THINK(30i40.)i 

coment:  nc  analyst  retrieves  the  authorization 
FORN  FOR  THIS  REQUEST! 

FERFORN  GET -COLE-AUTHORIZATION! 
conient:  sohe  reouirehents  imy  mready  RE  COVERED 
BY  PREVIOUS  REQUESTS! 

SOMETIMES!. 10..)! 

BEG-SOME! 

PERFORM  REJECT-REQUEST! 

END-SOME! 

COMMENT:  INCH  A  REQUEST  MILL  BE  FILLED*  lie  COLLECTION 
COORDINATOR  MTU  DETERMINE  WHETHER  FLYING 
MISSIONS  ARE  CAPABLE  OF  FILLING  TIC  REQUEST* 

IF  ■EXTERNAL ■  SOURCES  MUST  BE  CALLED  UPON. 

THE  ANALYST  MUST  ALERT  THE  SUPERVISOR! 
SOMETIMES!*:**)! 

BES-SQICf 

PERFORM  REROUTE-REBUESTi 
END-SOME! 

comment:  one  of  nc  currently  scheduled  recce  operations 
MY  BE  CAPABLE  OF  HANDLING  THIS  REOUEST! 

SOME TIMES!. 30..)! 

BEG-SOME! 

MODIFY CGOOlilll  «  'f'.G001ll2i  >  'CM!  THIS  MISSION 
COVER  THIS  REOUESTiTOOY'H 

TH1NKI5.10.K 
CHATTER  OIV-CHIEFI 
END-SOME! 

COMMENT:  SOIC  REQUESTS  MILL  REWIRE  THE  SOEDULIN6  OF 
A  NEM  MISSION! 

SOMETIMES!. 55**)! 

BEG-SOME! 

MOD1FY(G001«124  =  'CAN  THIS  BE  SCHEDULED?' >! 
THIHKIS.IO.)! 

CHATTER  OIV-CHIEFI 
DELETE* 

END-SEARCH! 

END-FLIC  EXTRACT -AMD-PROCESS-REWIREICXTS. 


PROCEDURE  MCI  AI*-T»-TlC-*-ftL£  MMtTM^TW 


abstract: 

NO  FORMAL  SCENARIO  HAS  DEED  KITTEN  FOR  THIS  PROCEDURE  - 
IT'S  PURPOSE  IS  TO  CONTINUAUT  AID  NEH  RECORDS  TO  TIC  S1A  AND 
61AA  FILE  SO  THAT  TIC  VERSION  OF  THE  COLLECTION-COORDINATION 
SCENARIO  WHICH  DELETES  RECORDS  HIU.  NOT  RUN  OUT  OF  SATA. 


PROCEDURE  KMC!  UPDATE 


tSUPDATE.FTNSS 


BEB-SCEN  UPDATE: 

conhent:  hessabes  are  enterinb  the  queue  of  the  update 

SCENARIO  AND  HIU  DE  PROCESSED  SEQUENTIALLY 
BASED  ON  PRIORITY  OF  HESSASEI 
PERFORH  NS8-INT0-F0RHI 

conhent:  tic  hessabe  hill  havc  a  unique  id  cox 

ASSI6NED  TO  IT  BEFORE  ADDING  IT  TO  THE 
DATABASE! 

PERFORM  ADD-HSS-TO-DBI 

COMMENT’.  DETERMINE  WHO  SHOULD  SEE  THIS  ICSSAGE  AND 
ROUTE  APPROPRIATE  1*0.  TO  THEIR  AUNT 
QUEUE.  IF  RECEIVING  ANALYST  CANNOT  BE 
DETERMINED.  ROUTE  TO  HATCH  OFFICER) 

SOMETIMES!  .85.  .11 
BEG-SOME) 

PERFORH  ROUTE-TO-ANALYSTi 
END-SOME) 

comment:  «cn  h  kw»t,  route  TIC  ICSSA6E  to  the 
HATCH  OFFICER! 

SOH£TIMES(.20>i)i 

BED-SOME) 

PERFORM  ROUTE-TO-UATCMi 
END-SOME) 

comknt:  mo  the  icssage  is  fully  processed  it 

SHOULD  K  REMOVED  FROM  TK  UPDATE  OUEUEI 
PERFORM  REMOVE -ME SSA6E! 

END-SCEN  UPDATE. 


t  '-■'•’A 


PROCEDURE  NAME:  MSS-INTO-FORM 


OHS6IF.FTNO 


K6-FUNC  MSB-INTO-fORM) 

coknt:  OVERLAY  INCOMING  ICSSAGE  ONTO  NSC.  FORM) 

DISPLAY  INTO  FORM  AOOt.li 

THIWI2.5.)) 

OO-FUNC  MSB-INTO-FORM. 


l*-» 


PROCEDURE  NAME!  DELETE 


isdeiete .finds 


ADSTRACT! 

Th*  KLETE  routine  it  used  in  conJuKtion  with  the 
UPDATE  scenario  to  rrtvnt  tht  ADAtAS  ttssatt  files  fm 
ovtrflovinA  thtir  taxiiut  record  litii, 

When  called.  DELETE  till  sierly  rttovt  ill  records  (w 
tht  eessaAe  Tilts  thtt  have  ben  created  by  tht  UPDATE  sennit. 


axmmmfjaxaxtr.tattrrrtmtTTrrimrmrrtrft£ftTntrrtrfTtmTTr^ 


PROCEDURE  NMCi  DISPLAY  WDISPLT.FTNB 


ADSTRACT! 

THE  DHIl  ■DISPLAY"  COMMAND  IS  USD  TO  DISPLAY  AN  ALEUT 
QUEUE  ENTRY  TO  TIC  TERMINAL.  THE  RTE  FORMAT  IS! 

DISPLAY  Kaltrt  nutbtr»ClNTO  FORM  <uttrviw>» 

NTH  ARE  OPTIONAL  PARAMETERS.  HKI 
<tlirt  nutb»r>  -  THE  MINDER  OP  THE  AURT  QUEUE  ENTRY  TO  K 
DISPLAYED.  IF  NOT  SPECIFIED.  DEFAULT  TO 
HIGHEST  PRIORITY  ALERT  QUEUE  ENTRY. 

INTO  FORM  <ustrviM>  -  PARAMETER  USED  DY  THE  UPDATE  SCENMII 
TO  DISPLAY  M  KERT  QUEUE  ENTRY  INTO  TK 
SPECIFIES  <«strviw>  FORMAT. 


CCCCCCIXCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC^ 


PROCEDURE  NAME!  THINK 


abstract: 

THINK  sieulates  an  analyst  eulliRA  over  a  decision.  Itcautt  of 
this,  tht  result  is  divided  bv  tht  altrt  status.  Obviously,  tht 
analyst  will  think  less  lite  in  a  crisis  or  uar  situation. 


c 

c 


procedure  kmc:  enter 


uun.mm 


i 

abstract: 

TX  MIL  W  COMMA*  IS  USED  IS  SIMULATE  TX  ANALYST 
ENTERING  DATA  INTO  A  HKVIOUSLT  DISPUTED  FOM.  0M.T  TX  CONTEXTS 
OF  TX  BISPLAT  AAE  MODIFIED  -  THIS  COMMA*  MAS  NO  EFFECT  ON  IX 
DATABASE.  SUDSEOUEXT  PRIMITIVE  DIRECTIXS  CONTROL  TX  IlSnSITION 
OF  TX  DATA. 

TX  RTF  COMMAND  FORMAT  IS! 

ENTER! Tfieldnaoe)  =  <neu  value)E.<f itldnaue)  =  <neu  value)!)! 
PARAXTERS  ARE! 

<fieldnaoe)  -  TX  NAX  OF  TX  FIELD  KCEIVIN6  DATA 
<m  value)  -  VALUE  TO  K  ASSUMED  TO  RECEIVING  FIELD 

FOR  TX  RTE>  THIS  COMMAND  M1U  K  EXECUTED  AS  A  ‘MATT*  TIX 
C 

c 


c 

C  PROCEDURE  NAX!  ROUTE  MROUTE.FTNU 

C 

c 

c  abstract: 

c 

C  The  DHIL  coeeand  ROUTE  it  used  Is  insert  eettete  inforMtion 

C  into  the  alert  eueue  of  an  analyst. 

C 

C  The  RTE  com  and  foreat  is! 

C  ROUTEIIOGIN  =  <reccivins  analyst).  HS6-IB  =  Cfield  value)) 

C  RRI  =  <field  value).  SUBJ  »  <field  value))l 

C 

C  Reeuired  raraeeters  are! 

C  LOGIN  —  the  losin  identifier  of  the  receivins  analyst 

C  KSG-ID  —  the  tss-id-code  vhich  unieuely  identifies  a  eessade 

C  uithin  the  dated as 

C  PR1  —  the  tessase  priority 

C  SUBJ  —  brief  information  indicatins  the  subject/content  of 
C  the  eessade 

C 

C  _  _ 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCtCCCCCCCCCCCCCCCCCCCCCCC 


C-38 


Start  Area  Analyele 
0 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


menus  wwc:  area-analysis  iwu,«w 


AUTHOR!  >  Nc2 

ABSTRACT! 

BE6-SCEN  MEA-ANALYSIS! 

COMMENT!  ANALYST  SCANS  ALERT  QUEUE  FOR  INCOKINE  ICSSAGES! 

FERFORN  REVIEU-INPUTSI 

COWENT:  ANALYST  DECIDES  IF  THE  HESSA6E  RCTRIEVEB  IS 

FERTINENT  AT  THE  HONE  NT i  AND  SHOULD  BE  INVESTISATEDI 

SOMETIMES!.?*,.!! 

BEG-SONES 

COHNENTi  SAVE  MESSAGE  BEFORE  CONTINUIN6S 

PERfORN  STORE-NSfii 

CONNENT!  ANALYST  NON  COME  ARES  MSS  1*0  WITH 
OB  HOLDINGS! 

PERFORM  C0MP-H0LDIN6S! 

COMMENT'.  BASED  ON  THIS  ItffO.  THE  ANALYST  Ml  HEED  TO 
UPDATE  THE  OB  DATA! 

SOMETIMES! .80, A, )i 
BEG-SOME! 

PERFORM  UPDATE-OBi 
END-SOME! 

COMMENT:  ANALYST  BEGINS  TIC  INVESTIGATION  BT  BUILDING  A 
NAP  OF  THE  AREA  AROUND  THIS  UNIT! 

PERFORN  BUILD-NAP! 

COMMENT:  THE  ANALYST  DECIDES  TO  EVALUATE  TIC 

SURROUNDING  AREA  FOR  ALL  UEAPONS  SITES! 

PERFORN  ADDL-DATA-REOUIREBi 

THINK! 15>30»A)! 

CONNENT ;  REOUEST  TECHNICAL  CHARACTERISIICS/CAPABILITIES 
OF  WEAPON  SYSTEMS  FOUND! 

PERFORN  GET-CAPABILITIES! 

conicnt:  the  analyst  decides  to  SEE  if  any  collections 

HAVE  BEEN  MADE  IN  THIS  AREA  RECENTLY! 

PERFORN  CHATTER-COLL-COORDi 

COMMENT:  IN  SONE  CASES,  nc  ANALYST  MY  FIND  IT 

NECESSARY  TO  HAKE  A  FORMAL  COLLECTION  REOUEST 
FOR  INFO.  NEEDED  TO  PROCEED  WITH  ASSESSMENT! 

SOMETIMES!. 10, A)>! 

BEG-SONEi 
PERFORN  COLL -RED! 

PERFORN  DONE-PROCESSING! 

END-SOME! 

CONNENT:  THE  ANALYST  HAS  ENOUGH  INFO.  TO  CONTINUE, 

AND  SO  DECIDES  TO  CONFER  WITH  MC  TO  FIND 
ALL  MISSIONS  SCHEDULED  IN  THE  AREA! 

FERFORN  CHATTER-MAC! 

COMMENT:  THE  ANALYST  CONTINUES  ASSESSMENT  BT  OVERLAYING 
ROUTE  INFO.  ONTO  NAP! 

PERFRON  PLOJ-FLT-ROUTESi 

comment:  the  analyst  non  makes  am  ASSESSKXT  of  tic 
POSSIBLE  IMPACT  ON  CURRENT  OPERATIONS! 

THINK(5,10,)I 

CONICNT:  WHEN  TIC  ANALYST  DETERMINES  THAT  A  DEFINITE 
TWEAT  EXISTS,  A  BRIEFING  IS  PREPARED  FOR  THE 
DIVISION  CHIEF /SUPERVISOR! 
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c 

c 

t 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


SO€TKS(.25t»il| 

m-ma 

(mot:  the  analyst  first  updates  the  nissioi 
RECORD! 

PERFORM  MISSION -UPDATE! 

CONKNT!  MMLTST  SAVES  A  COPY  OF  T*  IW  FOR 
USE  IN  MUTING! 

PERFORM  STBUWI 

comment:  the  analyst  requests  indicator  lists 

EVALUATE  FOR  PERTINENCE  AND  CURRENCY) 
PERFORM  EXAMINE- INDICATORS) 

COMMENT  I  ANALYST  DILL  ACTIVATE  APPROPRIATE 
INDICATORS  IIHERE  NECESSARY! 
SOMETIMES!  .JO.A.W 
BE6-SEMC! 

PERFORM  ACT1VATE-1ND1CA10RSI 
END-SOME) 

PERFORM  PRESENT-BRIEFING) 

PERFORM  PREPARE-MSG! 

END-SMC! 

END-SOME) 

END- SEEN  AREA-ANALYSIS. 


caccccccccacccccccccccaccccccccccaxtxccaOTCccccccmwttuxcaxcccc 


ccccccccccccccccccccccccccccccccccccccccccccacaxccccccccccccaccccccccc 

c 

C  PROCEDURE  NAME!  REVIEW-INPUTS  MREVINP.ORAtt 

C 

C 

f  abstract: 

c 

C  KS-FUNC  REVIEN-IWUTS! 

C  COMMENT!  DISPLAY  NUMBER  AND  KIND  OF  EACH  ENTRY  IN  QUEUE! 

C  ALERT! 

C  THINKI10.3Q>A)i 

C  COHKENi:  DISPLAY  SHORT  TITLE  -  ALL  QUEUED  ALERTS! 

C  SCAN! 

C  THINK!  10. 30.  AH 

C  COMMENT;  SELECTIVELY  DISPLAY  AMD  READ  A  MESSAGE  FROM 

C  THOSE  ROUTED  THROUGH  THE  ALERT  QUEUE! 

C  RETRIEVE  (AOQI.it  A001H  EQ  MM) 

C  THINK(30.90.A)i 

C  PAGE! 

C  THINK(30»90iAIf 

C  END-FUNC  REVIEW-INPUTS. 

C 

C 

C 

c 

ccccccccccccccccccccccccccccccccccctccccccccitccccacctcccctccccccccccccc 


N 

c 


PROCEDURE  NA*!  DU1LD-AREA-HAP  UBBLDMAf .FTKBW 


C 


:  ABSTRACT i 

C  BES-fUNC  BUILD- AREA-NAP! 

:  comment:  anxyst  builds  a  nap  of  toe  aka  referred  to  in 

l  TIC  MCMMC!  - 

C  HAPdAT  «  *«•  i LON  »  •$*.  )t 

C  THHK12.5.  H 

C  END-FUNC  BUILD-AREA-NAP. 

C 

C 


C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


PROCEDURE  NAIC:  ADDL-DATA-REDUIRED  MADLDAT.ORAO 


abstract: 

BEG-fUNC  ADX-DATA-REOUIREBI 

cowent:  a  re  oust  is  mk  for  im  on  all  surface-to-air 
MISSILES  AND  ANTI-AIRCRAFT  ARTILLERY  VITHIN  A  200KX 
RANGE  OF  THE  PREVIOUSLT  IDENTIFIED  UNIT! 
THINKI5.10.)! 

CSEARCHTCOOi.liCOOltlllA  ED  'SA*  OR  C0010111A  ED  'AA'. 

LAT  =  C001B41  iLOM  «  C001M1A. RANGE  >  200KHH 
BEG-SEARCHi 
THINK(2rS.)» 

REVIEW 

THIMKIOitSiAH 

page; 

THINK (10. 1S> A) i 

cohhent:  analyst  mill  selectively  plot  those  units 

THAT  NAT  HAVE  AN  IMPACT  IN  THIS  AREA! 
SOMETIMES!. SO. A. H 
BE6-S0MEI 

PLOT!  .CLASS  =  COOllltlA.  )( 

END-SOME! 

END-SEARCH! 

END-FUNC  AODL-DATA-REOUIREO. 


INPUT 

LDA  -  logon  iS<U  iru 

LAT  -  Uie  lelitude  of  the  unit  identified  in  the  M, 
LON  -the  longitude  of  the  sue  unit 
ALTFL6  -  jlert  stAtus 


cccacttaccccccacccracccccccccccccaxmatxccttcaxaxccacccaxccax 

c 

c  procedure  name:  cmatter-coll -coord  imchtcol.ftn«« 

c 

c 

c  abstract: 

C  BE6-FUNC  CHATTER-COLL-COORBi 

C  INSERT: 1  .BLOCK  =  -HAVE  ANYTHING  ON  THIS  AREA  ?’>» 

C  THINK!5.10.  >i 

C  CHATTER  COLLECTION -COORDINATOR! 

c  comment:  after  sending  a  copy  of  the  hap  to  tic  collection 

C  COORDINATOR.  Tt€  ANALYST  Via  WAIT  FOR  A  REPLY 

C  BEFORE  CONTINUING) 

C  THINM300.400,  )i 

c  comment:  the  analyst  is  scanning  the  alert  oueue  for  a  response; 

c  scan; 

C  THINM5.10.  )i 

c  display; 

c  THINK(20.M.  )t 

C  END-FWC  CHATTER-COLL-C0OKD. 

c 
c 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 
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PROCEDURE  NAME!  C0U.-RE0 


ItCOLREO.ORAtt 


I 

i 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

£ 

c 

c 

c 

c 

c 


abstract: 

BEG-fUNC  COLL-REO! 

comment:  analyst  displays  and  fills  in  collection 
REQUEST  FORKS! 

FORK  6001.1! 

IHINKIS.IO.I! 

ENTER<G001I3  =  •»’  .600114  =  T, 6001143  =  COOIMOII 
TNINK(120.180.» 

comm:  after  competing  tk  reduest  form,  the  analyst 
STORES  IT  IN  THE  DATABASE! 

ADDON  G001.1S 

COMMENT:  TIE  ANALYST  CAN  NO  L0N6ER  CONTINUE  ON  THE  CURRENT 
ASSESSMENT  UITH  THE  INFO.  AT  HAND! 

END-fUNC  COLL-REQ. 


C  input: 

C  C1A040  -  Urttl  coifilrn  code  for  twint 

C 

C 

ccccccccccccccccccccccccccccccacccccccccccccccccccccccccaxccccccccccccc 


ccccccccccacaccccccaccccccccaxcraxcaxccccccaxccccttccctxcaxcccccc 

c 

C  PROCEDURE  NAME!  NISSION-UPDATE  MNSNUPD.ORAtt 

C 

C 

c  abstract: 

C  BE6-FUNC  NISSION-UPDATE! 

C  RETRIEVE(H001.1,H00H2  EO  Tit 

C  THINK(5,15.)i 

C  N0DIFYIH00H31  =  1  HATCH  FOR  SAN’)! 

C  END-FUNC  NISSION-UPDATE. 

C 

c 


cccccccccccccaccccaccccaccccccccccccccccccccccacccccaccccccccccccca 

c 

C  PROCEDURE  NAME:  CHATTER-MAC  IMCHTMAC.FTNttt 

C 

C 

c  abstract: 

C  BEG-FUNC  CHATTER-NACi 

C  INSERT!. .BLOCK  =  'ANY  MISSIONS  IN  THIS  AREAT'H 

C  THINKI5.I0.  ). 

C  CHATTER  MAC-ROUTE-THREAT-ASSESSi 

C  COMMENT:  THE  ANALYST  WAITS  FOR  MAC  TO  RESPOND  UITH  MISSION-IDS 

C  FOR  ALL  OPERATIONS  IN  THE  AREA! 

C  THINKI300.400.  >! 

C  SCAN! 

C  THINKI5.10,  II 

C  DISPLAY! 

C  THINKC20.30.  )i 

C  END-FUNC  CHATTER-MAC. 

C 

C 

cccccccccccccaccccccccccccaccccacccccccccccccccccccctccccaccccccccccc 
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rr ^  a  at- 
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■  .  M. 

•;V'V\ 
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■*  •  • 

V/’ 

1 

cccccc 

c 

-  ' 

c 

PROCEDURE  NAME:  STORE-MR  ItSTOHAR.FTNt* 

.  */ 

t 

*,■  ’  * 

c 

abstract: 

-  „•  X 

.*  .  *.  • 

_ 

t 

KHUHt  SYOREHW1 

’  - ij 

c 

CONNENT!  STORE  TIC  FULLY  CONSTRUCTED  KAR  FOR 

r— : 

c 

LATER  USE  IN  BRIEFINGS; 

"  * 

'  s' 

c 

STORE! 

■ 

c 

END-fUNC  STORE-WAR. 

t  \ 

c 

c 

IXCLC 

XCCCCCCCCCCC£CCCCCCCCCC(XCCCCC(XCCCCCCC(£CtXC(^ 

cacxcccccaaccixccccccccaaxccaaxcamccccccccccccaxixccccccaxca: 

•  .  ‘ .  1 

.*_• 

c 

V" 

c 

PROCEDURE  name:  exahine-indicators  oexhind.orau 

\ 

»v 

c 

\ ' 

c 

ident:  G80-007.a 

*  .  ‘ 

t’.* 

L* 

N 

c 

TASK  name:  AW  SCRIPT  OR  FUNCTION)  LINK  N/DHIL.OLB 

c 

c 

Srss#! 

c 

AUTHOR:  >  Hc2 

c 

*  -*■  A 

c  • 

c 

abstract: 

’  .*  *.*• 

f.’ 

c 

8EG-FUNC  EXANINE-INOICATORSi 

K* 

c 

CaWENT:  THE  ANALYST  REQUESTS  ALL  KILITARY  INDICATORS 

.  •*« 

c 

FOR  TIC  COUNTRY  OBSERVED! 

■*. 

c 

OUERYIFOOl.liFOOIll  EO  C001I40  AND  F001I21  EQ  'NIL')! 

/ 

c 

THINK!  10.15))! 

c 

PACE! 

c 

THINKU0.15.)! 

C 

ENO-EUNC  EXAMINE-INDICATORS. 

.  - 

c 

•* 

c 

input: 

-  ‘ ,  * 

»  ** 

c 

C1A040  -  count n  cod* 

. ’ 

c 

-  ‘  A.  -H 

1- 

c 

_ . [  ...r . .  . . It))"- 

c 

c 

PROCEDURE  NAME:  ACTIVATE-INDICATORS  MACTIND.ORAtt 

■ 

t 

’  -v  *  •, 

c 

*'*■*-. 

► 

c 

abstract: 

♦ 

c 

BEG-FUNC  ACTIVATE-INDICATORS! 

c 

CONNENT:  UPDATE  TIC  INDICATOR  STATUS! 

j 

c 

MODIFY (F001 N24  =  *A')i 

9 

c 

COMMENT :  THE  ANALYST  IWES  HARDCOPY  FOR  LATER  REFERENCES! 

'V 

9 

c 

HARDCOPY! 

a 

c 

c 

THINM5.10.K 

EHD-FUNC  ACTIVATE-INDICATORS. 

AA' 

rf  ' 

» 

*• 

» , 

.* 

r. 

%\%V . 

*  '  *  '  - 

-•< 

-  -  -  T  »  »•« 

**. 

■s 

• 

* 

- 

.\ 

* 
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\  ‘ 

* 

•  . 

> 

a 

1 

-/  ■  A\ !  ’  v\.\v 

-  „* 

-i-;  >  ' 

Li 

-  -  '  .■'V-  .'-A'.'-  .-V-  ‘ ."V ""vL>^‘ 

*'»  **,  *s,  v.  i*.  -  } 

V* V* 

procedure  wuc:  present  briefing  probe. ora 


abstract: 

BEG-FUNC  PRESENT-BRIEFING 

coahekt:  aaalyst  displays  the  rjllt  constructed  mri 

RECALL! 

THINKdOO'iOO.Ali 

COHHEHT!  AS  AN  AIDE  IN  BRIEFING  TIC  ASSESSHENTi  tw 
ANALYST  HILL  IDENTIFY  THE  HISSION  IN  DMNSER 
UITH  light peh/cursur  and  display  iwo  about 
THE  ROUTE! 

AMP! 

THIHN(300i400»A)i 
EHD-FUNC  PRESENT-BRIEFING. 


ccccccaccccacccccccccccacccccaaaccccccccccccccaaxacaticaxcccccc 

c 

C  PROCEDURE  NAHEI  PREPARE-HSG  UPREHS6.0RAU 

C 

c 

c  abstract: 

C  BEG-FUNC  PREPARE-HSG! 

C  COHMEHT.  ANALYST  RETRIEVES  HESSA6E  FORHAT  AND  ENTERS 

C  APPROPRIATE  DATA! 

C  FORK  A001.lt 

C  TH1NKI5.10.  >i 

C  ENTERTAOOltl  =  T.A00H71  =  ‘IMWOltlfO  =  ‘SAN  HARKINGS 

C  A001D200  =  'HESSAGE  TEXT')! 

C  THINK(30i40»  )! 

c  connent:  the  harning  NESSAGE  NILE  be  added  to  the  database 

c  HESSAGE  FILEiTHE  ANALYST  HILL  HAKE  A  PERSONAL  COPT 

C  THEN  ROUTE  TtC  HESSAGE  TO  TK  SUPERVISORS  ALERT  OUEUEI 

C  ADDON  A001.ll 

C  HARDCOPY! 

C  THINK(5»10f  >! 

C  ROUTETLWIN  =  'DIV-CHIEF'.HSG-ID  =  A001I1.PRI  =  Ti 

C  SUIJ  «  *SAH  IWRNIN6')! 

C  END-FUNC  PREPARE-HSG. 

C 

c 

ccccccccccccccccccccccccccccuccraccccccccccccccccccccccccccacccccccccc 
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PROCEDURE  NA*:  ALERT 


abstract: 

THE  BHIL  •STMS*  COWWHD  IS  USE®  TO  SAVE  TIC  CURRENT  SCREEN 
DISPLAY  (KAP/RECORD)  IN  A  TEMPORARY  FILE  FOR  FAST  RECALL  AT  A  LATER 
TINE.  ONLY  THREE  'RECORDS'  CAN  BE  STORED  AT  ANY  TINE.  AND  TICY  ARE 
ACCESSED  ON  A  LAST-IN  FIRST-OUT  BASIS  VIA  THE  'RECALL'  COWAND. 

FOR  THE  RTE.  THIS  COMMAND  VIU.  BE  EXECUTED  AS  A  'NAIT  TINE. 


procedure  name:  hardcopy 


itHRDCPY  .FTRtt 


ABSTRACT! 

THE  DHIL  * HARDCOPY'  COMMAND  IS  USED  TO  FORMAT  AKD  TRANSFER 
AU.  OF  TTC  CURRENT  DISPLAY  TO  A  HARDCOPY  DEVICE. 

THE  RTE  COMMAND  FORHAT  IS! 

HARICOPYi 

TIC  COWAND  Hill  BE  ISSUED  AS  A  WAIT  TIME  FOR  TIC  BENCHMARK 
EXERCISES. 


■ccccccccrtcccccccccco:cccttcixccccamcaxctxcccccccaxxcaxmi 


c 

C  PROCEDURE  NAME!  FORM  tlFORM.FTNtt 

C 

C 

c  abstract: 

C 

C  The  FORM  coteand  is  used  to  display  the  to  Relate 

C  foraat  for  the  seecified  uservieu. 

C 

C  The  RTE  cooaand  foraat  is! 

C  FORM  <uservieu>> 

C  This  cooaand  is  used  to  display  a  fora  uhich  will  then 
C  have  intonation  ENTERed  into  it  by  the  analyst  (a  seouence 

C  of  steps  used  to  add  a  record  to  the  database).  For  testing 

C  purposes  this  conand  uill  be  executed  as  a  WAIT  tiee. 


C 

C 

C 

C 

C 

C 

C 

C 

c 

c 


PROCEDURE  NAME:  ROUTE  -  ROUTE  A  MESSAGE  TO  ANOTHER  ANALYST 


abstract: 

ROUTE  executes  a  uait  tiee  that  simulates  an  analyst  typing  in 
another  analysts  ID  and  sending  hia  a  eessage. 


Start  Scenario 


\ 

£ 


i 


K- 


fe1 

$? 


k  •- 

kt 


k 

& 


>  .-■ 

►V- 


Info.  Indicates  |£ 
New  Site 
Plot  It 


Plot  all  Weapon 
Sys  In  Area  j 
of  Msg. 


Check  Other 
Sources  for  I 
Additional  Data! 


Request 

RECCE  Mission 

Figure  C-5  Military  -  Systems  -  Analysis 
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c 

C  PROCEDURE  NAHEi  HIL-SYS-ANAL  UHIISYS.ORAII 


BEG-SCEH  HIL-SrS-MMLi 

COIDCNTI  IWALTST  IS  SCAWIKS  ALERT  QUEUE  FOR  INC0HIN6 
HESSA6ESI 

PERFORH  REVIEW-INPUTS* 

CONTENT  I  AN  INVESTIGATION  IS  WARRANTED  IF  TIC  NESSA6E 
CONTAINS  NEW  OR  UNUSUAL  SYSTEMS  DATA! 
SOHETlHESf.Wuli 
BEG-SOME  t 

PERFORM  STORE-HSSI 

CONNENTI  THE  NESSAGE  NAT  PERTAIN  TO  SEARCH  (LONG-RANGE) 
RADAR  ONLY; 

SOMETIMES!  «34*  t)t 
BEG-SONE! 

CONNENTI  TTf  ANALYST  IDENTIFIES  AND  PLOTS  ALL 
SYSTEMS  IN  THE  AREA  IDENTIFIED  IN  THE 
NESSAGE! 

PERFORH  PLOT-RADAR-SITES! 

CONNENTI  AFTER  STUDYING  THE  Ntf  >  TIC  ANALYST 
DETERHINES  THAT  ADDITIONAL  DATA  IS 
REQUIRED  TO  EXPLAIN  TIC  NESSAGE! 

THINK! 10. IS. I! 

PERFORH  CHECK-OTHER-SOURCESi 

CONNENTI  WHEN  OTHER  SOURCES  CANNOT  EXPLAIN  DC 

HISSING  IIFORHATION.  A  FORHAL  COLLECTION 
REQUEST  BECOMES  NECESSARY! 

SOHET1NESI.20. .)! 

BEG-SONE! 

PERFORH  SYS-COLL-REQi 
PERFORH  DONE-PROCESSING! 

END-SMC! 

CONNENTI  WHEN  INFO.  FRON  OTHER  SOURCES  VERIFIES 
THE  NESSAGE.  THE  ANALYST  PROCEEDS  IT 
ASSESSING  THE  INPACT  ON  CURRENT  OPNS! 
CONNENTI  INFO.  INDICATES  A  NEW  SITE! 

PERFORH  PLOT-NEW-SITE) 

PERFORH  OVERLAT-HSNSi 
PERFORH  UPDATE -RADAR-IICOi 
SOMETIMES! .30. . ) i 
BEG-SOHEi 

PERFORH  CHATTER-NEW-SITEi 
END-SOME! 

PERFORH  D0NE-PR0CESSIH6I 
END-SOME! 

comment:  if  we  got  here... 

comment:  the  message  pertains  to  a  particular 

WEAPON  SYSTEM! 

CONNENTI  THE  ANALYST  IDENTIFIES  AND  PLOTS  ALL 

SYSTENS  IN  THE  AREA  IDENTIFIED  IN  TIC  MSS! 
FERFOfiH  PLOT-SAH-SITESi 

CONNENTI  AFTER  STUDYING  TIC  NAP.  TIC  ANALYST  DETERHINES 
THAT  ADDITIONAL  DATA  IS  REQUIRED  TO  EXPLAIN  THE 
ICSSAGEi 


c 

c 

c 

t 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

t 

c 

c 

c 

c 

c 

c 


tmukoms.ii 

perform  Dcanmo-souttii 

ctmim  wot  emu  suas  cnmot  dtuii  the  mniM 

XNT0AHAT10N,  A  FORMAL  COLLECT! 0«  HUH 
BECOMES  ttCESSARTI 

sonniffS(.so<»)» 

BEG-SOME) 

PERFORM  SYS-C0LL-R£0I 
PERFORM  DONE -PROCESS IMG) 

END-SOME! 

comment:  wen  info,  from  ona  sources  verifies  nc 

MESSAGE i  DC  ANALYST  PROCEEDS  BT  ASSESSING 
TME  IMPACT  ON  CURRENT  OFNS) 

SOMETIMES!  .»••» 

BEG-SOKI 

comjcnt:  info,  indicaies  a  NEH  SITE) 

PERFORM  PtOT-NEN-SAM) 

PERFORM  OVEREAT -MSNSi 
PERFORM  UPDATE-SAN-ltfOt 
SOMETIMES!. 3Dn)t 
BEG-SOME) 

PERFORM  CHATTER-NEV-SANI 
END-SOlCi 


PERFORM  DONE-PROCESSING) 

END-SOME) 

comment:  if  he  got  here... 

comment:  INFO.  INDICATES  INCREASED  CAPABILITIES) 

PERFORM  PLOT-INC-CAP, 

PERFORM  OVERLAY-MSNS) 

PERFORM  UPDATE-SYS-OATAi 
SOMETIMES!. JO,.)) 

BEG-SOME) 

PERFORM  CHATTER-INC-CAPi 
END-SOME) 

END-SOME! 

END-SCEN  MIL-SYS-ANAL. 


C 

C  PROCEDURE  NAME!  REVIEH-INPUTS  IIREVIMP.ORAll 

C 

C 

c  abstract: 

c 

C  BEG-FUNC  REVIEH-IMPUIS) 

C  COMMENT:  DISPLAY  NUMBER  AKJ  RIM?  OF  EACH  ENTRY  »  GUEUE) 

C  ALERT! 

C  THINK! I0.30.AI) 

C  COMMENT!  DISPLAY  SHORT  TITLE  -  AU.  OUEUEO  ALERTSB 

C  SCAN! 

C  THINX!J0,30,A)I 

C  COMMENT!  SELECTIVELY  DI5PLAY  AND  READ  A  ICSSA6E  FROM 

C  THOSE  ROUTED  THROUGH  THE  ALERT  GUEUE) 

C  RETRIEVE  (AOOJ.I,  A001I1  ED  Til 

C  THINK!30,M,A>) 

C  PAGE) 

C  THIMKUO.M.A!) 

C  END-FUNC  REVIEH-INPUTS. 

C 

C  CALLED  BY:  HATCH-FUNCTION 

C 
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V.v, 


PROCEDURE  NAME!  STOK -HSS 


USTOMSG.FTW* 


C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


ABSTRACT! 

l£S-f!)NC  STORE HISS) 

comment:  store  tic  input  icssas  ir  a  teipormt 
PERSONAL  Fill  FOR  LATER  USE! 

STORE! 

END-FUNC  STORE  HISS. 


ccccccccccccccccccccccracccccccccaxaxcaxcraiixcccccaxccLCcccaxccca 

c 

PROCEDURE  NANF.I  PLOT-SAM-SITES  UfEOTSS.ORAU 


abstract; 


BEG-FUNC  PLOT-SAM-SITES) 

COMMENT!  THE  ANALYST  BUILDS  A  NAP  OF  THE  AREA 
REFERENCED  IN  THE  MESSAGE) 

PERFORM  BUILD-AREA-MAP  I 

comment;  TIC  ANALYST  SEARQCS  FOR  MO  PLOTS  ALL 
SAM  SITES  I  OF  THE  IKNTIFIED  TYPE) 

KNOW  TO  BE  IN  TIC  AREA) 

CSEARCH1E002.1, £002*140  EO  'SAM'  AND  £002*142  CD  '«*> 
LAT  =  'ft  LON  =  •«'.  RANGE  *  SOONDI 
BEG-SEARCH! 

THINM2.3,)) 

comment;  ANALYST  SUICKLY  SCANS  EACH  RECORD 
BEFORE  PLOTTING  LOCATION  ONTO  MAP) 

REVIEW 
THINK! 10. IS.) I 
PLOT!. CLASS  =  'SMI'.)) 

THINK! 2.5. I) 

COMMENT:  ANALTST  INDICATES  SAM  RANGE  ON  MAPI 
CIRCLE!, RANGE  *  '**)) 

END-SEARCH) 

END-EUNC  PLOT-SAM-SIIES. 


aCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCaXIXCaCCCTCCCCCCCCCCCCCCCCCCCCCCCCCC 


t 


procedure  NMc;  Qcn-oTHn-souxxs 


MOKOS.FTNtt 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


abstract: 

B£6-fUNC  CJECK-OTIER-SOURCESI 

comment:  the  analyst  hiu  recall  ttc  message 

REIMS  INVESTIGATES!  AM)  SEND  A  'COPT* 

Of  THE  MESSAGE  TO  THE  HATCH  OFFICER 
AND  COLLECTION  COORDIMTOR  -  REQUESTING 
ANY  INFORMS  TtCY  NIGHT  HAVE) 

RECALLS 

ENTERTAOOlim  =  ‘ANYONE  KNOU  ANYTHIN6  ABOUT  THIS?* >1 
CHATTER  HATCH-OFFICER.  COLLECTION-COORDINATORS 
THlHKIIOOi&OOiIS 

conhent:  tie  analyst  hatts  for  SOKE  REPLY! 

SCANS 

THINK(5.15i)S 

CONSENT:  ANALYST  HAS  RECEIVES  A  CHATTER  OF  TIE  ICSSAGE 
UITH  A  RESPONSES 

DISPLAYS 

THINK(lO.lOi)) 

STORES 

END-F1SNC  CHECK-OTHER-SOURCES. 


caccccccccccccccccrauicnxccccacccccaxccaiaimmccaccccccccccra 

c 

C  PROCEDURE  NAME:  STS-COLL-REO  ItSYSCOL.ORAU 

C 

C 

c  abstract: 

c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 
c 


DE6-FTJNC  STS-COLL-REQS 

comment:  the  analyst  displays  and  fills  in  collection 

REQUEST  FORMS 
FORM  G401.lt 
IHISKISilttSI 

ENTER(G001I3  =  600114  =  ‘1‘.  6001U3  =  ,»‘)l 

THINK(120tl80f  )l 

COMMENT:  AFTER  COMPLETING  TIE  REOUEST  FORM.  TIC 
ANALYST  STORES  IT  IN  THE  DAT  ABASE  I 
ADMIN  6041.11 

COMMENT!  CURRENT  OPNS  SHOULD  BE  NOTIFIED  THAT  TIE 
ASSESSMENT  COULD  NOT  BE  COMPLETED  - 
SEND  A  COPT  OF  TIE  MESSAGE! 

RECALL! 

ENTER(A041171  =  'NOTIFY  OPNS  -  CAN'T  VERIFY  MHAT'S 
OUT  THERE') I 
THINK(5tl4t )l 
CHATTER  DIV-CHIEFi 

COMMENT:  ANALYST  CAN  NO  LONGER  PROCEED  HITH  CURRENT 
ASSESSMENT! 

END-FUNC  STS-COLL-REO. 


ccccccccccacccccccacccccccccccccacc^^ 

c 

C  PROCEDURE  NAME!  CHATTER-NEIf-SITE  UCHTNSI ,mw 

C 

c  abstract: 

c 

c  BE6-FUNC  CHATT£R-«N-SITE> 

C  INSERT!. .BLOCK  =  'NOTIFY  OPNS  “  HEN  RADAR  SITE  HAS 

C  BEEN  VERIFIED* )i 

C  TMNKIS.IO.II 

C  CHATTER  DIV-CH1EFI 

C  BREAXS 

C  END-FUNC  CHATTER-tfR-SITI. 

C 

c 

ccccccccccccccccccccccacccccccctcaxcccacccccccccccccaxccccccccccccccc 


cccccccccccccccccccixtccccaccccimccccccccaOTCcccaccraccccaxcccccc 

c 

PROCEDURE  NAME:  PIOT-SAH-SITES  UPLOTSS.ORAM 


abstract: 


B£6-fUNC  PLOT-SAh-SITESi 

content:  the  analtst  builds  a  nap  of  the  area 

REFERENCED  IN  TIE  MESSAGE! 

PERFORM  BUILD-AREA-NAPI 

COMMENT*.  THE  AMALTST  SEARCHES  f»  AMD  PLOTS  NLL 
SAM  SITES  (OF  THE  IDENTIFIED  TTPE) 

KNONN  TO  BE  IN  THE  AREA! 

CSEARCHIE002.1.E002IHO  ED  *SAM*  AND  E002B1A2  ED  *»*> 
LAT  =  *»*.  ION  =  •!*,  RANGE  =  SOOKHAI 
BEG-SEARCHi 
TH1NK(2i5i)I 

comment:  ANALTST  QUICKLY  SCANS  EACH  RECORD 
BEFORE  PLOTTING  LOCATION  ONTO  MAPI 

REVIENi 
THIWUO.15.li 
PLOT!. CLASS  =  ‘SAHM! 

THINM(2.5.)i 

COMMENT!  ANALTST  INDICATES  SAM  RANGE  ON  NAP! 
CIRCLE! .RANGE  =  *»*!! 

END-SEARCH. 

END-FUNC  FLOT-SAN-SITES. 


[tjliYu'oj 


PSOCtHJK  NMC!  PLOT-NEH-SAN 

abstract: 


wpltnsa.ftnw 


BE6-FUNC  PLOT-NEN-SAHi 

cowon:  anoticr  source  has  i Demina  t*  coordinates 

OF  A  NEN  SMI  SITE.  THE  ANALYST  PLOTS  THIS 
INFORMATION  MID  CONTINUES  ASSESSMENT) 

INSERT (CLASS  =  ‘SAMS. BLOCK  =  'NEH  SAN')I 
THINKISflSi  )■ 

CIRCLE!  .RANGE  =  *•*)» 

ENWUNC  PLOHEN-SMT. 


acccccccccccccccccccccacccccacccccacccccccccccccciicccccccccccccccctt 

c 

C  PROCEDURE  NAME:  OVERLAY -MSNS  MOVHSNS.ORAU 


BEG-FUNC  OVERLAY-HSNS) 

PERFORM  CHATTER-MAC) 

COMMENT!  MAC  HILL  EVALUATE  THE  AREA  AND  RETURN  THE 
MISSION-IDS  FOR  ALL  SOCIU.ED  MISSIONS  IN 
TFC  AREA) 

COMMENT :  THE  ANALYST  HILL  REOUk  T  AND  PLOT  All 
INFORMATION  ON  THESr  MISSIONS) 

PERFORM  PLOT-FIT-ROUTESi 
END-FUNC  OVERLAY-MSNS. 


accccccaccccccaccccccccccctxccccccccaccccaccaccacccaxcccaxcccctc 


ccccccccccccccccccccccaxccccccaccaxccccccccccacccccaxcaaccccccccct 

c 

C  PROCEDURE  NAME:  UFBATE-SAM-INFO  MUPDSMt.ORAtt 


PEG-FUNC  UPDATE-SAM-INFO) 

COMMENT !  THE  ANALYST  DUST  UPDATE  THE  DATABASE 
TO  REFLECT  TTC  NEH  SAMI  S1TEI 
RETRIELEIE00T.1.E002B1  EQ  •»*)) 

THIHKU0.20.lt 
HODIFYIE0O2I143  =  MM) 

EMD-FUNC  UFDATE-SAMHITO. 


MCHYNSA.FYNW 


c 

c  mccnM  kmc:  chatter-ndf-sm 

c 
c 

C  ABSTRACT! 

t 

C  K6-FUNC  CHATTER HCK-SMII 

C  INSERT! i>BC OCR  =  *HARN  OPNS  -  NEB  SAN  SITE  HAS 

C  BEEN  VERIFIES*)! 

C  THINK<5»10.>I 

C  CHATTER  01V-CMEF! 

C  BREAK! 

C  END-fUNC  CHATTER -ICN-SAA, 

C 

c 

ccccacccccccccccccccccccccccccccccccncctcccoxcaxcixccttcccccccccccccc 


ccccccccccaxctcaxcaxccccaccccccccccccccccccccaxcccccccacccccccccccc 

c 

c  PROCEDURE  NAHE!  CHATTER-INC-CAP  UCHATIC.FTNM 

C 

C 

C  ABSTRACT! 

C 

C  BE6-FUNC  CHATTER-INC-CAP! 

C  INSERT!,. BLOCK  -  "NOTIFY  OPNS  -  INCREASED  CAPABILITY 

C  FOR  THIS  SYSTEM  HAS  BEEN  VERIFIED*)! 

C  THINK(5rl0i>! 

C  CHATTER  DIV-CHIEFi 

C  END-FUNC  CHATTER-INC-CAP. 

C 

C 

ccccccccccttccccccaccacccaccccccccttcaccccccccccccccccccaxcoxcixc^ 


cccccccccccccccacccccccccccaccccaxccccccaxcacacccccccccccacccccccc 

c 

C  PROCEDURE  HAHE!  UPDATE-SYS-BATA  UUFSYSD.ORAU 

C 

C 

C  ABSTRACT! 

C 

C  BEG-FUNC  UPDATE-5TS-DATA! 

C  COHMENT!  ANALYST  RETRIEVES  THE  RECORD  FOR  THIS  SYSTEM 

C  RETRIEVEIDOOl.liDOOlIl  EO  ‘SAN1  AND  DM1B2  ED  Til 

C  THINKS, 10,  )l 

C  CONTEXT!  ANALYST  CORRECTS  DATA  BASED  ON  CONTENT  OF 

C  MESSAGE  AND  EVALUATION! 

C  HODIFYIDOOIMO  =  '»•)! 

C  END-FUNC  UPDATE-SYS-DATA. 

C  CALLED  BY!  NIL-SYS-ANAL 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCU.CCCCCCCCCCCCCCCCCCCCC 


C-57 


cccccciraccccccccccccccraccccitt^ 

c 

C  PKOCEMJRE  name:  thin* 


THINK  siaulates  an  enalvst  aullins  over  >  decision,  Because  of 
this,  the  result  is  divided  by  the  elert  sUtus.  Obviouslvi  the 
analyst  will  think  less  tiee  in  1  crisis  or  mr  situation. 


-  INTE6TR!  Hinieua  reacetiae  wait 

-  INTEGER!  flaxiaua  wit  it  ms  tin 

-  INTEGER!  Alert  status  (1.2,3) 


ccccccmccctccaccccixcccacaracoxtxmxxaxatiacccaxccaxcccccttc 

r 


EROCEtNJRE  NANE1  ALERT 


ALERT  will  sieulite  an  analyst  displacing  nuabers  and  tvn 
of  aessaaes  on  the  alert  oueue.  The  actual  aessases  are  not  relev  an 


c  procebuke  name:  scai 

c 

c 

c  abstract: 

c 

C  SCAN  siaulates  an  analyst  scmnind  throwh  the  list  of  alert 

C  aessases. 

C 

C 

ccccccccctmctxcccccccaccctxcracccccccccctuxtctmcmcttaxraxccax 


PROCEDURE  hahe:  SICK 


anginaci; 

THE  Mil  ‘STORE1  CCiflWfl)  IS  USED  TO  SAVE  Tt€  CURRENT  SCREEN 
DISPLAY  (HAP/RECORD)  IN  A  TEHPORAfiY  FILE  FOR  FAST  RECALL  AT  A  LATER 
TINE,  ONLY  THREE  ‘RECORDS1  CAN  BE  STORED  AT  ANY  TIHEt  AW)  TFCT  ME 
ACCESSED  ON  A  LAST-IN  FIRST-OUT  BASIS  VIA  THE  ‘RECALL1  COMBS. 

FOR  THE  RTEi  THIS  COHNAND  NIU.  BE  EXECUTED  AS  A  ‘BAIT1  TINE. 


PROCEDURE  NANEI  BUILD-AREA-NAP  WtBLDHM.FTNnt 

IDENTI  080-007, XX 

TASK  nahe:  any  script  or  function,  liw  B/DHIL.OLB 

author:  ,  Hc2 

abstract: 


BEG-FUNC  BUILD-AREA-HAPi 

cohnent:  analyst  builds  a  iw>  of  the  area  referred  to  in 

TIE  KESSAGEi 

NAPILAT  »  ‘I*  ,LON  *  ‘B‘i  It 
THINKI2.5,  It 
END-FUHC  BUILD-AREA-HAP. 


xcccccaccccccccaaccaxccamccccoxccttaaxcccccccccccccaxx 

PROCEDURE  NANEI  CIRCLE  MClRCU.FTNtt 


ABSIkACT! 


THE  DHIL  ‘CIRCLE’  COHNAND  IS  USED  TO  DRAB  A  CIRaE  B1TH  THE 
SPECIFIED  RANGE  AROUND  AN  HEN  THAT  HAS  BEEN  IDENTIFIED  ON  TIC 
CURRENT  NAP  DISPEAT. 


THE  RTF  COHNAND  FORHAT  1ST 

CIRCLE!  C<fieldna»eXrelopXvalu«>IBlOCK<rtlOTXvjlue>J> 
RANGE  =  <rans*»l 


PAKAHETERS  ARE! 

<fi*ldnaw><rel0AXyalu«>  -  OPTIONAL  PARAMETER  BHICH  SPECIFIES  TIC 
ITEM  ON  DISPLAY  BHICH  SHOULD  BE  CIRCLED. 

BLOCK<r*IwXvJlue>  -  OPTIONAL  PARAMETER  BHICH  IDENTIFIES  TIC  ITEM 
BHICH  SHOULD  BE  CIRCLED  TWOUGH  IT'S  DATA  BLOCK  VALUE. 

RANGE  =  <ranM>  -  REOUIRED  PARAHETER  BHICH  SPECIFIES  TIC  RADIUS  Of 
THE  CIRCLE  TO  BE  DRABH.  (WtID  UNITS  ARE  NH  AND  KH,  DEFAULT 
TO  KH  If  HOT  SPECIFIED) 


C  PROCEDURE  KMC!  KOI  ttPLOT.FTNtt 

C 

C 

c  abstract: 

c 

C  THE  0HII  ‘PUJT‘  COHNUffl  IS  USO  TO  DISflAT  OBHS  ITEKS  OHIO  A 

C  PREVIOUSLY  SM  RATED  HAP  BACKGROUND, 

C 

C  THE  RTE  COHMAM)  FORMAT  IS! 

C  PLOT(t<uwrvi«.>><Yieldri.)»e>  <r«lo*>  <fieldvalue>  [<lo4»> 

C  <f ieldr^te)  <relof>  <fi»ldvalui>3].CUSS  =  <ss»6ol>> 

C  CBLOaiWOHOCXIli 

c 

C  PARAMETERS  ARE: 

C  <uservie«>i<f ieldfwie>. . .<f itldvalue>  -  OPTIONAL  SELECTION  LIST 

C  WHICH  WHEN  SPECIFIED  CAUSES  A  DATABASE  ACCESS  FOR  ALL  RECORDS 

C  THAT  KEET  THE  CRITERIA  TO  BE  PLOTTED  ONTO  TIC  Ktf. 

C  If  NCT  SPECIFIED.  PLOT  THE  INF  ASSOCIATED  WITH  THE  RECORD 

C  CURRENTLY  BEING  DISPUTED. 

C  CLASS  -  REQUIRED  PAP.AHETER  WHICH  INDICATES  THE  CLASSIFICATION  OF 
C  STKKlIC  DATA  TO  BE  PRESENTED  ON  TIC  HAP 

C  BLOCK  I  NOBLOCK  -  OPTIONAL  PAP.AHETER  WHICH  SPECIFIES  WHETHER  A  ‘DATA 
C  BLOU/TA6'  IS  10  BE  APf ENDED  TO  EACH  SYMBOL  GENERATED  FOR 

C  tlSPUT.  BLOCK  IS  THE  DEFAULT. 

C 

C  NOTE:  THIS  IS  TIC  ONLY  DHIL  COHHAND  THAT  WILL  EITHER  BE  EXECUTED  AS 
C  A  ‘WAIT'  TIHE  (WHEN  ISSUED  WITH  NO  SELECTION  LIST).  DR  HAKE  A 

C  DATABASE  ACCESS  (WHEN  ISSUED  WITH  A  SELECTION  LIST). 

C 

c  muimuutmmmtitmmmmmimmmtmmuttmttu 

c  iitmmmmimtuummmumummnmmummtmm 

c  IHITHIS  'PlCr  FUNCTION  SHOULD  ONLY  BE  CALLED  BY  FUNCTIONS  WHICHMtt 

C  IMIARE  ISSUING  A  DHIL  PLOT  COHHAND  WITHOUT  A  SaECTION  LISTSUUIUI 

c  tmmtttutmimmtmsmmmmmmmmmimttmstm 

c  ttitutmunntitmmmmmmummmmmmmuiumi 

c 
c 

ccccccccccccccccccccoxcccccccccccccccaccccccccccccccccccaccccccccccccc 


cccccccccccccccccccKccccccccccccccoxcccccccccccccccccccccacccaccccccc 

c 

C  PROCEDURE  NAME:  RECALL  IIRECAll.FTNtt 

C 

c 

c  abstract: 

c 

C  THE  DHIL  ‘RECALL’  COHHAND  IS  USED  TO  ACCESS  A  HAP/RECORD 

C  WHICH  HAS  HEN  STOREd  IH  A  TEHFORaRT  FILE. 

C 

C  THE  RTE  WILL  EXECUTE  THIS  COHHAND  AS  A  'WAIT'  TI* 


cccccccccccaccccccccacacaaccccccaccamacOTcaai cccccccccaxecc 
c 

C  PROCEDURE  *w:  ENTER  OENTER.FTNO 

C 

c 

c  abstract: 

c 

C  THE  DHIL  ‘ENTER*  COMMAND  IS  USED  TO  SINUATE  THE  ANALTST 

C  ENTERING  DATA  INTO  A  PREVIOUSLY  DISPLAYS!  FORM.  ONLY  TIC  CONTENTS 

C  Of  THE  DISPLAY  ARE  NODIFIED  -  THIS  CWWvO  HAS  NO  EFFECT  ON  TIC 

C  DATABASE.  SUPSEOUENT  PRIMITIVE  DIRECTIVES  CONTROL  THE  DISPOSITION 
C  OF  THE  DATA. 

C 

C  THE  RTE  CQHHAND  FORMAT  IS! 

C  ENT£R(<fieldnj»e>  s  <ne»  vjlueH.Cfieldnue)  5  <ne«  value)])! 

C 

C  PARAMETERS  ARE! 

C  <fiel<ffi3M>  -  TIC  NAME  Of  THE  FIELD  FICE1VIN6  DATA 

C  <ne«  value)  -  VALUE  TO  BE  ASSIGNED  TC  RECEIVING  FIELD 

C 

C  FM!  THE  RTE.  THIS  COMMAND  KILL  BE  EXECUTE!  AS  A  ‘HAIT‘  TI« 

C 

C 

ccccccccccccccccaccccccccccccccccccccccccccccaxaxccccccccccccccccccccc 


ccccccccccccaccccccccccccccccccccccccccccccccccccxccccccccccaccccccccc 


PROCEDURE  name:  CHATTER 


BCHTTER.FTNtt 


abstract: 


THE  DHIL  -CHATTER’  COMMAND  1$  USE}  TO  SEND  A  COPY  OF  THE 
CURRENT  TERMINAL  DISPLAY  TO  ANOTHER  ANALYST  TWOUGH  THE  ALERT 
QUEUE. 


THE  RTE  COMMAND  FORMAT  IS’. 

CHATTER  CreceivinH  LOGIN  identifier)  T.treceivinS  LOGIN  identifier)]? 


cccccccccccccccccccccccaccccccccccccccccccccccncnxcccccccccccccaxcccc 


C-61 


.  S-  ■  . 


Ivlev'S 


,  «  •  +  .  -  ■  *  *  1 


MDISPLY.FTNtt 


C  PROCEDURE  NAME!  DISPLAY 

c 
c 

c  abstract: 

c 

C  DC  DHIL  'DISPLAY'  COMMAND  IS  USED  TO  DISPLAY  AH  ALERT 

C  QUEUE  ENTRY  TO  THE  TERMINAL.  THE  RTE  FORMAT  IS! 

C 

C  DISPLAY  Kalert  nu*ber>HINTO  FORM  <us*rvie«>JI 

C 

s.  sum  »I  oruortnL  rMcHHETEltS)  utCAEI 

C  <alerl  nu*ber>  -  THE  NUMBER  OF  THE  ALERT  QUEUE  ENTRY  TO  BE 
C  DISPLAYED.  IF  NOT  SPECIFIED.  DEFAULT  TO 

C  HIGHEST  PRIORITY  ALERT  OUEUE  ENTRY. 

C  INTO  FORM  <uservieu>  -  PARAMETER  USED  BY  THE  UPDATE  SCENARIO 
C  TO  BISPLAY  AN  ALERT  OUEUE  ENTRY  INTO  THE 

C  SPECIFIED  <userviee>  FORMAT. 

C 

C 

C 


C 

C  PROCEKKE  NAME!  FORM  UFORM.FTNtt 

C 

C 

c  abstract: 

c 

C  The  FORM  coaaand  is  used  to  display  the  template 

C  foraat  for  the  specified  uservieu. 

C 

C  The  RTE  ctmand  foraat  is! 

C  FORM  <uservieu>! 

C  This  cctaand  is  used  to  display  a  for*  Which  uill  then 
C  have  inforaation  ENTERed  into  it  Du  the  analyst  (a  seouenct 
C  of  steps  used  to  add  a  record  to  the  database).  For  testin* 

C  Purposes  this  coaaand  uill  be  executed  as  a  BAIT  tiae. 

C 

c 


ccccccccccaccaxcccccccccacccccaxaxccccttcaxcccacccraxccraxram 

c 

C  PROCEDURE  NAME:  CHATTER-MAC  MtCHTHAC.FTNKI 

C 

c  abstract: 

C  BES-FUHC  CHATTER-MAC! 

C  INSERT! ..BLOCK  =  'ANY  MISSIONS  IN  THIS  AREA!')! 

C  THINMS.lOi)! 

C  CHATTER  MAC-ROUTE-THREAT-ASSESSI 

C  COMMENT!  T«  ANALYST  WAITS  FOR  MAC  TO  RESPOND  WITH 

C  MISSION-IDs  POR  ALL  OPERATIONS  IN  THE  AREA! 

C  THINM300.600.li 

C  SCAN! 

C  THM(5.10.)r 

C  DISPLAY! 

C  THINM20.30.)I 

C  END-FUNC  CHATTER-MAC. 

C 


PROCEHRE  NAME!  PUT-flT-ROUTES 


nn.Titn.ttMi 


c 

c 

c 

c 

c 

c 

t 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

t 

c 

c 


abstract: 

BES-fUNC  PLOT-FU-ROUTESI 

COMMENT!  TIC  ANALYST  DILI  REQUEST  AU.  MISSION  UrORNATItt 
TO  OVERLAY  ON  PREVIOUSLY  CONSTRUCTED  MAP. 

BASER  ON  THE  INFO.  HAC  SENT  I 
SONET IICS< .30,A.L00P=3)I 
BES-SONEi 

RETRI£VE(H041.1.H441t2  ES  ***»» 

IHIHrU20.JOO.AII 

CONJOn:  PLOT  THE  DEPARTURE  POINT  AND  TA6  EACH  ROUTE 
WITH  ITS  HISSION-IDI 
PLOT (.CLASS  *  'HSN'.li 
THINKt5.10.>! 

INSERT < it  BLOCK  =  H001I2)! 

CO«®n:  THE  ANALYST  REQUESTS  AND  PLOTS  ALL 
SEGMENT  INFORMATION! 

SEARCH! 1042. 1.1002170  EQ  H041I2II 
BEC-SEARCHi 
THINK (S.IO.)i 
REVIEW! 

THINKUO.JO.I! 

SEG(iiTOP-LAT  *  I002B7 . TOF-LON  =  I002I7A) 
END-SEARCH! 

END-SOME! 

END-FUNC  PLOT-FLT-ROUTES. 


ccccacccccccccccccaaactmccccccccccctxcccaccccraracccccccaxccccc 

c 

C  PROCEDURE  NAME!  INSERT  MINSERT.FTNtt 

C 

C 

c  abstract: 

c 

C  THE  DHIL  'INSERT'  COMMAND  IS  USED  TO  ADD  A  NEV  ITEM  TO  TIC 

C  SPECIFIED  LOCATION  ON  THE  CURRENT  NAP  DISPLAY  NITH  A  DATA  BLOCK 

C  APPENDED  TO  IT.  OR  TO  ASSOCIATE  A  DATA  BLOCK  WITH  AN  ITEM  ALREADY 

C  ON  THE  CURRENT  MAP  DISPLAY. 

C 

C  THE  RTE  COMMAND  FORMAT  IS! 

C  INSERTIECLASS  =  <ss«tol>MLOC  =  <vjluf>3, BLOCK  =  <v»lue»! 

C 

C  PARAMETERS  ARE', 

C  CUSS  *  <S',«bol>  -  OPTIONAL  PARAMETER  WHICH  SPECIFIES  TIC  SYMBOL 06T 

C  CLASSIFICATION  OF  THE  ITEM  BEING  ADDED  TO  THE 

C  DISPLAY. 

C  LOC  =  <v»lu*>  -  OPTIONAL  PARAMETER  WHICH  SPECIFIES  TIC  LOCATION 

C  VALUE  OF  THE  ITEM  BEING  ADDED  TO  THE  DISPLAY. 

C  IF  NOT  GIVEN,  DEFAULT  TO  THE  CURRENT  LOCATION 

C  OF  IHE  CURSORA IGHT  PEN. 

C  BLOCK  =  <vjlue>  -  REQUIRED  PARAMETER  WHICH  SPECIFIES  TIC  DATA  BLOCK 
C 

accccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccca 


Start  Scenario 


PROCEDURE  NAME:  NAC-ROUTE-ASSESSICWT  XWWXTE.ORAH 


author:  f  Hc2 

ABSTRACTS 

BEG-SCEN  NAC-ROUTE-ASSESSNENT I 

CONCtTS  ANALYST  SCANS  ALERT  QUEUE  FOR  ASSIGNED  HISSIONSi 
PERFORM  SCAN-OUEUES 

COMMENTS  analyst  retrieves  mission  and  ROUTE  DESCRIPTION 
INFORMATION  AND  PLOTS  ON  6RAPHICS  TERMINALS 
PERFORM  PLOT-MSNI 

COMMENTS  ANALTST  REQUESTS  COUNTRY  SUMMARY  INFO. i 
PERFORM  COUNTRY-INFOS 

COMMENTS  ANALTST  REQUESTS  ALL  01  INFO  TO  LOCATE 

UNITS/WEAPON  SYSTEMS  FOR  COUNTRY  INVOLVE!) 

PERFORM  SEAROHMS 

COMMENTS  ANALTST  MAT  NEED  MORE  INFO  ABOUT  A  PARTICULAR 
WEAPON  SYSTEM'S  CAPABILITIES! 

SOMETIMES!. SOi  .LOOP  =  3>S 
BEG-SOMES 

PERFORM  FIND-STS-CAPi 
ENB-50MES 

COMMENT!  ANALTST  REQUESTS  INFO.  FOR  All  ON-GOING  EVENTS 
WITHIN  TIC  COUNTRY  IN  QUESTIONS 
PERFORM  SEARCH-EVENTS! 

consent:  analyst  reouests  Ml  indicators  for 

COUNTRY  IN  OUESTIONi 
PERFORM  QUERY -INDICATORS: 

COMMENT:  ACTIVATE  APPROPRIATE  INDICATORS) 

SOMETIMES!. 30.A.  IS 
BEG-SOMES 

PERFORM  ACTIVAIE-INDICAIORSI 
END-SMC; 

COMMENTS  BASED  ON  I  (FORMAT  ION  RETRIEVED.  THE  ANALYST 
DETERMINES  IF  A  POSSIBLE  THREAT  EXISTS 
FOR  THIS  MISSIONS 
S0METIHESI.20.A.  IS 
BEG-SOME I 

C0N1ENTS  SITUAIION  NAT  require  NOTIFICATION 
TO  CURRENT  OPHSI 
PERFORM  NOTIFY-OPMSi 

COMMENTS  IF  TWEAT  EXISTS.  PRESENT  BRIEFING! 

PERFORM  BRIEF-ASSESSMENTI 

COMMENTS  IF  THREAT  EXISTS.  IT  NAT  BE  NECESSARY  TO  ISSUE 
WARNING  MESSAGE! 

SOMETIMES!. 20.  .)) 

BEG-SOMES 

PERFORM  PREPARE-MSG! 

END-SOME! 

END- SOME! 

END-SCEN  MAC -ROUTE-ASSESSMENT. 


PROCEDURE  NAME!  SCMt-MIE 


mSCMUE.FTNttt 


c 
c 
c 

c  abstract: 

C  BES-fUNC  SCAN-flUEUE! 

c  comment:  incn  am  operation  HAS  BEEN  SCHEDULES i  MAC  IS  CALLS 

C  UPON  TO  EVALUATE  THE  KSISMATEt  ROUTE! 

C  CONNER*:  TIC  ANALYST  IS  SEARCHINE  THROUGH  THE  ALERT  OUEUE 

C  TO  FIND  MISSIONS  UHICH  HAVE  BEEN  ASSIGNED  FOR 

C  EVALUATION! 

C  ALERT! 

C  THINKU0.30.Ali 

C  SCAN! 

C  THIHKU0.30.AI! 

C  DISPLAT! 

C  THINK(30.?0.A)! 

C  END-FUNC  SCAN-OUEUE. 

C 

C 

c 

ccccccccccccccccccccccccccccccccccccccccacccctcccccccccccccaccccccccccc 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


PROCEDURE  NAME!  PLOT-HSN  upltnsn.orau 


abstract: 

BEG-FUNC  PLOT -MSN! 

COMMENT!  REQUEST  AND  READ  TIC  MISSION  DATA! 
RETRI£VE(H001.1iH00U2  CO  •»•)! 

THIWU0.30.A1I 

COMMENT:  CREATE  A  NAP  BACKGROUND  OF  THE  AREA! 
HAPiLOC  »  H001I7I! 

THINKL2.5.  )! 

CONS  NT',  PLOT  THE  MISSION  DEPARTURE  POINT! 

PLOT!, CLASS  =  'HSN'.li 
INSERT!  .  .BLOCK  =  H001B2I! 

THINKIS.10.  I! 

comment:  THE  AMALTST  REOUESTS  1W0.  ON  ALL  ROUTE 
SEGMENTS.  AND  OVERUTS  ONTO  MAPI 
SEARCHU002.1. 1002*70  EO  H001B2H 
BEG-SEARCH! 

THINK12.5.  )l 
REVIENi 

THIWU0.30.  )! 

SESt  I  .TO-LAT  «  1002*7, TO-LON  =  I002I7A) 

END- SEARCH! 

END-SOICI 

END-FUNC  PLOT-MSM. 


PROCEDURE  MNC!  C0UNTRT-1NF0 


UCONHF.ORABt 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


abstract: 


8E6-FUNC  COUNTRY-INFO. 

RETRIEVE (E001  *TfE001t2  EQ  H00U71! 
THINK(10.3S>A)i 
ENU-FUNC  COUNTRY-INFO. 


CALLED  BY!  MAC-ROUTE-ASSESSMENT 

calls:  THltt.  OSOL.  obims.  odfinn.  oexec.  OFETCH 


PROCEDURE  NAME!  SEARCH-OI 


USRCHOt.ORASt 


ABSTRACT! 

BEG-FUNC  SEARCH-Oi; 

COMMENT:  REQUEST  ALL  UNITS  HITHIN  500KM  OF  ROUTE! 
CSEARCHICOOU.LAT  =  '1‘iLON  =  T.RANGE  =  500HUI 
BEG-SEARCHi 
THINK(2.Si  )l 
REVIEW 

THINK  UO, 90, AH 

COMMENT!  IF  LOCATION  OF  UNIT  AND  NEAPON  SYSTEMS  HAW 
IMPACT  ON  MISSION  ASSESS!**!  -  PLOT! 
SOMETIMES!  ,50. A.  H 
BEG-SOME! 

PLOT!,  aASS  =  ’I')! 

THINM2.5.  )i 

INSERT!.  .BLOCK  *  C001H11BH 

THINM2.S.  >i 

END-SOME! 

END-SEARCH! 

END-FUNC  SEARCH-OI, 


ccccccccccccccaccccccccccaccccccccraxccccccccccccccccccccccccccccccra 


PROCEDURE  NAHE!  FIND-SYS-CAPA8IL1TIES  IlFMCAP.ORAIt 


C 

c 
c 

c  abstract: 

C  BEG-FUNC  FIND-SYS-CAPI 

c  coment:  analyst  identifies  system  capabilities  froh  tw 

C  NEtfON/EOUIPHENT  SYSTEM  FILE! 

C  RETRIEVE!  DOOM  .DOOM  Ed  *»'  AMI  D001I2  EO  MM) 

C  TH1NK(5.10.)I 

c  comment:  tic  analyst  indicates  the  range  on  nap 

C  TO  DETERMINE  llffACT  ON  CURRENT  OPNSI 

C  CIRCLE! (RANGE  -  OOOIMOII 

C  END-FUNC  F1ND-SYS-CAP. 

C 

c 

c 

ccacccaccccccccccccccacccccatxixcccctccccctccccaxiccctccccctxcccccci 


ccccccacccaccccccccccaccccccccccccccaccccccccccccaiccccccccccccccca: 

c 

C  PROCEDURE  NANE!  SEARCH-EVENTS  ttSRCHEQ.ORAI* 

C 

C 

c  abstract: 

C  BEG-FUNC  SEARCH-EVENTS. 

C  QUERY (BOOM .8001123  EQ  E00II2  AND  BOOltli  ED  *»•)» 

C  THINK(30.300.A)i 

C  page; 

c  XHm<3o,m,Aii 

C  END-FUNC  SEARCH-EVENTS. 

c 

c 

c 

acccccctccccccccccccccccccccccccxcccccccccccccccaxtxccccccxcccccaccccc 


ccccccccccccccccacccccccccrxcccaaaccccccccccccccccccccccaxcccccccca 

c 

C  PROCEDURE  HAHEI  QUERY-INDICATORS  WQRYIND.ORAn 

C 

c 

c  abstract: 

C  BEG-FUNC  QUERT-INDICATORSi 

c  comment:  the  analyst  REQUESTS  ALL  INDICATORS 

C  FOR  COUNTRY  AND  QUICKLY  SCANS  TICXt 

C  OUERYIFOOM.FOOIII  E8  E001I2). 

C  TH1NK(30»130.A). 

c  page; 

C  THINR(30.150fAli 

C  END-FUNC  QUERY-INDICATORS. 

C 


c 

C  PROCEDURE  NASI  ACTIUATE-INDICATORS  UACTIND.ORABt 

C 

C 

c  abstract: 

c 

C  8E6-FUNC  ACTIVATE-INBICATORSi 

C  comment:  UPDATE  THE  INDICATOR  STATUS) 

C  hOBIFY ( F001B2A  *  'A*)) 

c  comment:  nf  analyst  hakes  hardcopt  FOR  LATE*  REFERENCES) 

C  HARDCOPT  i 

C  THim(SilOi)) 

C  END-fUNC  ACTIDATE-IW1CATORS. 

C 

C 


C 

C  PROCEDURE  NAK!  NOTIFY-OPHS  ntNFTOPN.FTNm 

C 

C 

c  abstract: 

C  BEG-FUNC  NOTIFY-flPNSI 

C  INSERT ( >  i (LOCK  =  ‘HATCH  THIS  AREA*)) 

C  THIHK(2i5i  )l 

C  CHATTER  GPNS -OFFICER! 

C  END-FUHC  NOTIFT-OPHS. 

C 

c 


c 

c  PROCEDURE  NAHE!  BRIEF -ASSESSMENT  IttBRFASM.FTNBtt 

C 

C 

c  abstract: 

C  BEG-FUHC  BRIEF-ASSESSIWTI 

C  THINK(300i600pA)I 

C  AW! 

C  THINKOM.iOOiA)) 

C  END-FUNC  BRIEF -ASSESSMENT. 

C 

C  CALLED  BT:  MAC-ROUTE-ASSESSMENT 

C 

C 


C-69 


■••/vvv  /t.w.r**' 


<•  f 


c 

C  PROCEDURE  NAME!  DISPLAY  uomr.mia 

t 

c 

c  abstract: 

c 

C  THE  DH1L  'DISPLAY'  COMMAND  IS  USED  TO  DISPLAY  AK  ALERT 

C  OUEUE  ENTRY  TO  THE  TERMINAL.  THE  RTE  FORMAT  IS! 

D 

C  DISPLAY  Ktltrl  nuobtrMUNTO  TOM  <us*rvi«>Tl 

C 

C  BOTH  ARE  OPTIONAL  PARAMETERS i  WHERE! 

C  <slfrt  nuobrr)  -  THE  NUMBER  OF  TIE  ALERT  OUEUE  ENTRY  TO  K 
C  DISPLAYED.  IF  NOT  SPECIFIED.  DEFAULT  TO 

C  HIGHEST  PRIORITY  ALERT  OUEUE  ENTRY. 

C  INTO  FORM  <us*rvi«>  -  PARAMETER  USED  IT  TIE  UPDATE  SCENARIO 
C  TO  DISPLAY  AN  ALERT  OUEUE  ENTRY  INTO  TIC 

C  SPECIFIED  <uurviN>  FORMAT. 

C 

C 

c 


ccaicccccacccaaacccccccacccccaccccacccccraTmxccaxccaccamc 

c 

C  PROCEDURE  NAME!  HAP  tMAP.FTNtt 

C 

C 

t  THE  mi  'MAP'  COMMAND  IS  USED  TO  GENERATE  A  MAP  BACKGROUND. 

C 

C  THE  RTE  COMMAND  FORMAT  IS! 

C  MAPICOORD  =  <dro. coords. >  I  LOC  =  (iodtian  nw>. 

C  t SCALE  «  <scJlf>])i 

C 

C  PARAMETERS  ARE! 

C  COORDILOC  -  MUST  SPECIFY  EITHER  COORD  OR  LOC  (BUT  NOT  BOTH) 

C  TO  IDENTIFY  THE  CENTER  POINT  OF  THE  DISPLAY 

C 

C  SCALE  -  OPTIONAL  PARAICTER  WHICH  SPECIFIES  THE  SCALE  OF  THE 
C  NAP  TO  BE  DISPLAYED.  SCALES  AVAILABLE  ARE!  1I20M. 

C  UGH.  r.lH>  USOOKi  1 ?M i  UIOCN.  IISOMi  K2». 

C  1!10K.  C7.SK.  IF  NOT  SPECIFIED.  DEFAULT  TO  1T20H 

C 

c 

axacaacccccccccccccccixaccccaxccccaxctacixnxtxcccccxccaixcccccc 


C-7  0 


procedure  name:  pwaae-n* 


untfst.am 


ABSTRACT S 

BE6-FUNC  PttRARE-HSG! 

cowent:  analyst  retrieves  hessace  forhat  and  enters 

APPROPRIATE  DATAI 
FORM  AOtl.ti 
THlNKiS.lO.  )i 

ENTER ( AOC1  tl  =  ‘»SA001I71  =  T.AC01I1W  =  ‘SAN  UttNTN6S 
AC01B200  =  ’HESSAGE  TEIT'll 
THIW(30,M.  IS 

COmENT!  PC  HARNING  HESSAGE  HILL  BE  ADDED  TO  THE  BA1ABASE 
ICSSAGE  FILE. THE  ANAL  1ST  HIU  HAKE  A  PERSONAL  COPT 
PCJt  ADU7E  PC  KCSMH  10  THE  SUPERVISORS  PLEAT  QUEUE  I 
ADDON  AOCl.lt 
HARDCOPTi 
THIWiS.ld.  It 

ROUTE  <  L06IN  =  ‘DIV-CH1EFSHS6-ID  =  A001U.PRI  =  MS 
SUIJ  =  ‘SAN  UARNIN6 * > > 

ENWUNC  PREPARE -NS8. 


accccccccaacccccaaccccamccccccccccccccoxcccaxccaccccaxccaxcc 

c 

C  PROCEDURE  NAfC!  ALERT 


ALERT  Kill  situlate  an  analyst  diselayins  numbers  and  tyees 
of  aessades  on  the  alert  eueue .  Th»  actual  aessades  at*  not  relevant 


ccccccaccccccccccccccaccaxccccaxcccEcccccccccaxtxcEcoxaxacccccccc 


PROCEDURE  HAHEl  THINK 


THINK  situlales  an  anoint  lUlind  over  a  decision.  Because  of 
this,  the  result  is  divided  by  the  alert  status.  Obviously.  the 
analyst  mil  think  less  tiae  in  a  crisis  or  ear  situation. 


INPUT! 


H1N  -  INTEGER!  Hiniiuo  eeacetiae  wait 
HAT  -  INTEGER!  Haxiout  wait  at  any  tiae 

ALERT  -  INTEGEPi  Alert  status  <1.2.3! 


PROCEDURE  IWCI  SCAN 


abstract: 

SCAR  si^jlales  an  analyst  scanning  throu*  the  list  of  alert 
tessaaes. 


ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 

c 

C  PROCEDURE  NARE!  PLOT  MPLOT.FTNM 

c 

c 

c  abstract: 

c 

C  THE  DHIL  •FIOT'  CORRAND  IS  USED  TO  DISPLAT  DBAS  ITERS  ONTO  A 

C  PREVIOUSLT  GENERATE!'  RAP  BACKGROUND. 

C 

C  THE  RTE  CONHAND  FORRAT  IS! 

C  PLOT<[<userviey>*<fieldnaie>  <reloe>  <fieldva]ue>  tOoao*>> 

C  <fieldna»e'>  %reloe>  <f ieldvaiue>]l*CLASS  =  <syebol>t 

C  CBLOCKINQ  BLOCK])* 

C 

C  PARARETERS  ARE! 

C  \uservieu>*<fiel<)na«e>.. .<f ieldvalue)  -  OPTIONAL  SELECTION  LIST 

C  WHICH  WKN  SPECIFIED  CAUSES  A  DATABASE  ACCESS  FOR  ALL  RECORDS 

C  THAT  REET  THE  CRITERIA  TO  BE  PLOTTED  ONTO  THE  RAP. 

C  IF  NOT  SPECIFIED.  PLOT  THE  INFO.  ASSOCIATED  WITH  THE  RECORD 

C  CURRENTLY  BEING  DISPLAYED. 

C  CLASS  -  REQUIRED  RARARETER  WHICH  INDICATES  THE  CLASSIFICATION  OF 
C  STRPOLIC  DATA  TO  BE  PRESENTED  ON  T*  Rtf 

C  BLOCKINOBLOCK  -  OPTIONAL  PARAHETER  WHICH  SPECIFIES  WHETHER  A  'DATA 
C  BLOCK/TA6’  IS  TO  BE  APPENDED  TO  EACH  STRBOL  GENERATED  FOR 

C  D I  SPLAT.  BLOCK  IS  THE  DEFAULT. 

C 

C  NOTE;  THIS  IS  THE  ONLY  DHIL  CONHAND  THAT  WILL  EITHER  BE  EXECUTED  AS 
C  A  'WAir1  TIRE  (WHEN  ISSUED  WITH  NO  SRECTJON  LIST),  OR  IttKE  A 

C  DATABASE  ACCESS  (WHEN  ISSUED  WITH  A  SELECTION  LIST). 

C 

c  tmuMiimttiiitmtmtmstitmttmmttmmmumtmim 

c  tmsiitmmttmmmmmmmmmmutmtmmmmms 

C  HUIHIS  'PLOT1  FUNCTION  SHOULD  ONLY  BE  CALLED  BT  FUNCTIONS  WHICHtlU 

C  ItllAPE  ISSUING  A  DHIL  PLOT  COWAND  WITHOUT  A  SELECTION  LISTHimtSt 

c  tmmtmtiittmmutttMummtmmmimtmumtumm 

c  ttmitmmttmutmiitiMtumumummmtmumssmm 

c 
c 

ccccccccccccccccccccccccccccccccccccccccccccccccccccccccctccccccccccccccc 


ccccaxcacccacracaxaxttcccacccccaxcm^ 

c 

C  PROCEDURE  name:  imsekt  iiihkst.ftwi 

c 

c 

c  abstract: 

c 

C  THE  DHIL  'INSERT'  COMMAND  IS  USED  TO  ADD  A  NEW  ITEM  TO  TtC 

C  SPECIFIED  LOCATION  ON  THE  CURRENT  HAP  DISPLAY  HIM  A  DATA  BLOCK 

C  APPENDED  TO  ITi  OR  TO  ASSOCIATE  A  DATA  BLOCK  KITH  AN  ITEM  ALREADY 

C  ON  THE  CURRENT  I Vt  DISPLAY. 

C 

C  THE  RTL  COHHAND  PORHAT  1ST 

c  insert:  taAss  =  <s«boi>i.ax  =  <vj1u»>i, block  =  <v.iu*»i 

c 

C  PARAXTERS  ARE'. 

C  CLASS  =  <ss»hol>  -  OPTIONAL  PARAMETER  WHICH  SPECIFIES  TtC  STHB0L06Y 

C  CLASSIFICATION  Of  THE  I  TEN  BEING  ADDED  TO  TTC 

C  DISPLAY, 

C  LX  =  <vjlue>  -  OPTIONAL  FARAHETER  WHICH  SPECIFIES  TIC  LOCATION 
C  UAtUE  OF  TTC  ITEM  BEING  ADDED  TO  TTC  DISPLAY. 

C  IF  NOT  GIVEN.  DEFAULT  TO  I*  CURRENT  LOCATION 

C  X  THE  CURSORAIGHT  PEN. 

C  BLXK  =  <value>  -  REQUIRED  FARAHETER  WHICH  SPECIFIES  THE  DATA  BLOCK 

C 

C 

CCCCCtCCCXCCCCCCCCCCCCCCXCCCCCCCCCCCCCCtCCCCXCCCttCCIXCCCCCCCCCCXCCCC 


CCCCCCCCCCCCCCCttCCCCXXCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCt 

c 

c  FRXEDURE  NAftf :  SEB  MSE6.FTNU 

c 

c 

C  ABSTRACT : 

c 

C  TTC  DHIL  'SEG'  COHHAND  IS  USED  TO  DRAW  A  LHC  SEGHENY 

C  BETWEEN  TWO  POINTS  ON  A  DISPLAY. 

C 

C  THE  RTE  COHHAND  FORNAT  IS! 

C  SEG(CFROH-LAT  =  <f ro.-utiU*fe>.  FROH-LON  =  <frt*-lonsitixi*>J. 

C  TO-LAT  -  <to-l3tilu(fe>i  TO-LON  =  Yto-IwnilwJeMT 

C 

C  PARAMETERS  ARE! 

C  FROH-IAT  AND  FRON-LON  ARE  OPTIONAL  PARAHETERS  WHICH  SPECIFY 

C  THE  STARTING  POINT  X  THE  SEGMENT  TO  BE  DRAWN,  IF  NOI  SPECIFIED. 

C  DEFAULT  TO  THE  CURRENT  POSITION  X  TX  CURSOR /LIGHT  PEN, 

C  TO-LAT  AND  TO-LON  ARE  REQUIRED  PARAHETERS  WHICH  SPECIFY  TIC 

C  ENDING  POINT  X  THE  SEGMENT  TO  BE  DRAWN. 

C 

C 

ccccccccxccccccccccccccccccccccccccrxcccccccccccccccccccccccccacccccccc 


C-73 


cccccccccccccccxjxccccccccccccm:cccc(x<xccccccaxcccctcccccccccccccccccc 

c 

C  PROCEDURE  HAKE!  CIRCLE  ttCIRCU.FWII 

c 

c 

c  abstract: 

c 

C  THE  BUI  'CIRCLE'  COMMAND  IS  USEI  TO  DR  All  A  CIRCLE  UITH  DC 

C  SPECIFIED  RANGE  AROUND  AN  ITEM  THAT  HAS  BEEN  IDENTIFIED  ON  DC 
C  CURRENT  HAP  DISPLAY. 

C 

C  THE  RTE  COMMAND  FOKHAT  IS! 

C  CIRCLE(C<f  iel(Jnjw><r*l»Xv»lu*>IBLOCK<r«lofXvjIu(>Jr 

C  RANGE  =  <rjnS*»i 

C 

C  PARAMETERS  ARE! 

C  <fieldnM«Xrtlo?Xv3lu«>  -  OPTIONAL  PARAMETER  WHICH  SPECIFIES  DC 

C  ITEM  ON  DISPLAY  WHICH  SHOULD  BE  CIRCLED. 

C  BLOCK<relopXvjlue>  -  OPTIONAL  PARAMETER  WHICH  IDENTIFIES  DC  ITEM 

C  WHICH  SHOULD  BE  CIRCLED  THROUGH  IT'S  DATA  BLOCK  VALUE. 

C  RANGE  =  <fsrtSe>  -  REQUIRED  PARAMETER  WHICH  SPECIFIES  DC  RADIUS  Of 
C  THE  CIRCLE  TO  BE  DRAWN.  (VALID  UNITS  ARE  NN  AND  KM.  DEFAULT 

C  TO  KH  IF  NOT  SPECIFIED) 

C 

C 

ccccacccccccttccccccccccccccccccccccccccctxcccccccccccnxccccaccccaxcc 


accccccccccccccccccaccccccccccccccccccccccccccccccccccccccccccccccccccc 

c 

C  PROCEDURE  NAME;  HARDCOPY  MHRDCPY.FTNU 

c 

c 

c  abstract: 

c 

c  THE  DHIL  'HARDCOPY'  COMMAND  IS  USES  TO  FORMAT  AND  TRANSFER 

C  ALL  OF  THE  CURRENT  DISPLAY  TO  A  HARDCOPY  DEVICE. 

C 

C  THE  RTE  COMMAND  FORMAT  IS! 

C  HARDCOPTi 

C  THE  COMMAND  WILL  BE  ISSUED  AS  A  WAIT  TIME  FOR  THE  BENCHMARK 
C  EXERCISES. 

C 

c 

cccccccccccccccccccccccccccccccaccccccccccccccacccccccccccccccccccccccc 


ttiwm.nw* 


ramus  name:  ihsert 


abstract: 


TIC  MIL  ‘INSERT'  COMMAND  IS  USED  TO  ADD  A  NEl)  ITEM  TO  TTC 
SPECIFIED  LOCATION  ON  THE  CURRENT  MAR  DISPLAY  HITH  A  DATA  BLOCK 
AFfENXD  TO  IT.  OR  TO  ASSOCIATE  A  DATA  BLOCK  HITH  AN  ITEM  ALREADY 
ON  THE  CURRENT  M#>  DISPLAY. 


THE  RTE  COMMAND  FORMAT  IS. 

INSERTIECLASS  *  LsseboDl.CLOC  =  <vilu»>3, BLOCK  = 


Lvalue))) 


PARAMETERS  ARE! 

CLASS  --  -  OPTIONAL  PARAffiTER  UHICH  SPECIFIES  THE  SYMBOLOGY 

CLASSIFICATION  OF  THE  ITEM  BEING  ADDED  TO  TIC 
DISPLAT. 

LOC  =  Lvalue)  -  OPTIONAL  PARAMETER  WHICH  SPECIFIES  THE  LOCATION 
VALUE  OF  TIC  ITEM  BEING  ADDED  TO  THE  DISPLAY. 

IF  NOT  GIVEN.  DEFAULT  TO  TIC  CURRENT  LOCATION 
OF  THE  CURSORAIGHT  PEN. 

BLOCK  -  Lvalue)  -  REQUIRED  PARAICTER  HHICH  SPECIFIES  TTC  DATA  BLOCK 


ccccccccccccccaacacccccccttccaccccoaxacaxcctmcccaxccoxccccccc 

c 

PROCEDURE  NAME!  CHATTER  UCHTTER.FTNtt 


ident: 


task  name: 


author: 

abstract: 


680-007. XX 


ANY  SCRIPT  OR  FUNCTION.  LIMC  V/DKIL.OLB 
.  Mc2 


THE  DH1L  ‘CHATTER1  COMMAND  IS  USED  TO  SEND  A  COPY  OF  TTC 
CURRENT  TERMINAL  DISPLAY  TO  ANOTICR  ANALYST  TW0U6N  THE  ALERT 
QUEUE. 

THE  RTE  COMMAND  FORMAT  IS! 

CHATTER  LreceivinS  LOGIN  identifier)  l.Lreceivins  LOGIN  identifier)!) 


The  FORK  couand  is  used  to  display  the  tevWt* 
foriat  for  the  specified  uservie*. 

The  RTF  couand  format  is! 

FORM  ‘Cuservieyd. 

This  couand  is  used  to  display  a  fori  uhich  will  then 
have  inforialion  EKTERed  into  it  by  the  analyst  (a  seouence 
of  slees  used  to  add  a  record  to  the  database).  For  test ins 
purposes  this  coiaand  will  be  executed  as  a  1M1T  tin. 


ctcccccccaxccccccccccccccaccctccccctcaccccaxctxcKxcaccaccccaxcccc 


APPENDIX  D.  TASK  INFORMATION  BLOCKS  (TIBS! 


This  appendix  provides  a  more  detailed  description  of  the  the  Task 
Information  Blocks  (TIBs)  used  in  generating  the  I&W  data  base.  They  are 
important  in  showing  what  the  detailed  design  of  an  I&W  data  base  might 
look  like.  While  specific  formats  are  somewhat  arbitrary,  the  design  gives 
a  picture  of  an  overall  data  base  which  can  support  the  I&W  function  as 
defined  by  the  scenarios. 

Because  of  the  amount  of  information  contained  in  each  TIB,  only  one  of 
them  is  shown  in  detail,  in  Table  D-1 .  Other  TIBs  are  more  briefly 
described  in  the  text  that  follows.  A  full  set  of  TIBs  is  contained  in  the 
Interim  Technical  Report  for  this  project. 

TIB  #A001 ,  Message  Processing  Input/Output,  is  based  on  the  format  for 
GENSER  message  traffic.  It  can  be  accessed  only  through  its  unique  ID 
code.  The  format  for  A001  is  illustrated  in  Table  A-1. 

TIB  # B001,  Event  Log,  contains  extensive  information  concerning 
significant  events.  The  type  of  event  and  the  actors  in  the  event, 
together  with  estimates  of  source  reliability  and  accuracy,  are  included. 
Time  and  place  may  be  used  as  search  keys,  as  well  as  the  organizations 
participating  in  the  event.  Detailed  Identifications  of  personalities 
participating  in  the  event,  weapons  employed,  and  an  event  chronology  are 
included.  Other  associated  events  are  cross-referenced. 

TIB  IC001,  Order  of  Battle,  includes  standard  forms  for  OB  data.  The 
participating  unit  is  identified,  unit  organization  is  described,  and 
information  concerning  location  is  included.  Other  optional  information 
includes  unit  movement  information,  personnel,  equipment,  weapon  systems, 
and  tactics.  Information  concerning  logistics,  combat  effectiveness,  and 
related  personalities  Is  also  included. 
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TIB#:  A001  Functional  Area: 

TIB  Name:  Message  Processing  Input/Output 

Purpose/Use:  Based  on  the  format  described  for  GENSER  message  traffic 
Related  TIBs: 

Access  Rights: 

Item  Item  Size/Access 


Size/Access 
Struct.  Use 


Remarks 


Header 

Incoming  message 

15AN  Entry 

"  , 

unique  ID  code 

Format  line  1 

•All  files  in 

*  ' 

Validation  character 

1 A 

Block  1  should 

\v. 

Status  of  message 

HA 

be  packed  (no 

V* 

indicator 

spaces)  for 

£  «ps? 
.  •  .  * 

Start  of  message 

3A 

display  in  69 

.  -V-' 

indicator 

characters  or 

.  ■  «,"* 

Channel  sequence  number 

3N 

less  on  one 

\  - 

line. 

t:r;, 

Format  line  2 

M 

Communications  routing 

6  9  AN 

•Usually  not 

information 

shown. 

Format  line  3 

Prosign 

2A  +  1  blank 

•Display  as 

Table  D-1  Examples  of  Task 

Information  Block  (TIB) 

(Page  1  of  4) 

Item 

Item 

Size/ Access 

No.  . 

Description 

Struct.  Use 

Remarks 

42 . 

Originator  station 

7A  +  1  blank 

one  line  as 

routing  indicator 

indicated  with 

43. 

Station  serial  number 

5X  +  1  blank 

blanks  —  not 

(#  ) 

to  exceed  69X 

44. 

Julian  date 

3N 

characters 

45. 

Zulu  time 

4N 

total  line. 

+05 

Format  line  4 

•+05  and  +06 

51 . 

Security  warning 

3A 

refer  to 

operating  signal 

Format  line  4 

52. 

First  letter  of  message 

5A 

—  consisting 

security  classification 

of  one  or  more 

53. 

Communications 

23X 

lines  of  not 

operating  signal 

more  than  69 

printed  chars. 

+06 

Tango  addressee 

•May  repeat 

61. 

Special  transmission 

23X  followed  by  "T" 

100+  times. 

Each  addressee 

separate  line. 

+07 

Format  line  5 

71. 

Action  precedence 

1A  +  1  blank 

•Line  5  may 

• 

CM 

6- 

Info,  precedence 

1A  +  1  blank 

contain 

73. 

Date-time  group  of 

15  AN 

communications 

transmission 

operating 

signals  — 

+08 

Communications 

both  of  which 

operating  signals 

can  repeat  — 

81. 

Signal  for  book  message 

3A  -  optional 

but  the  entire 

82. 

Signal  for  correction 

3A  -  optional 

line  cannot 

exceed  69X. 
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Examples  of  Task  Information  Block  (TIB)  (Page  2  of  H) 


Item 


Item 


Size/ Access 


No. 

Description 

Struct.  Use 

Remarks 

+09 

Format  line  6 

•Line  is 

91. 

FM 

2A  + 

1  blank 

limited  to  58X 

Originator's  name  and 

55X 

■Begin  line 

address 

with  "FM  " 

+10 

Format  line  7 

•The  symbol 

100. 

TO 

2A  + 

1  blank 

"TO"  appears 

first  line 

+  11 

Addressee 

only. 

110. 

Routing  indicator/ 

55X 

■Addressee  may 

official  name 

repeat  500+ 

times . 

+12 

Format  line  8 

120. 

INFO 

HA  + 

1  blank 

•Line  8  begins 

with  "INFO  " 

+13 

Addressee 

followed  by 

130. 

Routing  indicator/ 

55X 

addressees  -- 

official  name 

same 

conventions  as 

line  7. 

+m 

Format  line  9 

•Same  as  lines 

1H0. 

XMT 

3A  + 

blank 

7  and  8  — 

first  line 

+15 

Addressee 

55X 

begins  with 

150. 

Routing  indicator/ 

"XMT  " 

official  name 

+  16 

Format  line  10 

•Hot  used 

Table  D-1  Examples  of  Task  Information  Block  (TIB)  (Page  3  of  4) 


Item 

Item 

Size/Access 

No. 

Description 

Struct.  Use 

Remarks 

+  17 

Format  line  11 

•Line  11 

170. 

BT 

2A 

consists  of 

+18 

Format  line  12 

text-boundary 

symbol  "BT" 

only . 

•Spaces 

180. 

Security  classification 

between 

j SY . 

Handling  caveats 

letters  except 

182. 

Sectional  message  ident 

. 

for  UNCLAS. 

+19 

190. 

Subject  line 

Subject  line 

6  9X 

•Not  strictly 

formatted. 

+20 

Text 

•May  repeat 

200. 

Message  text 

69X 

5000+  times. 

+21 

Format  line  13 

•Contains 

210. 

BT 

2A 

text-boundary 

+22 

Format  line  1H 

symbol  only. 

•Not  used. 

+23 

230. 

Format  line  15 

Station  serial  number 

5X 

•Same  as  +0H 

231. 

Two  carriage  returns 

2X 

#H3 

232. 

Eight  linefeeds 

8X 

+2H 

2H0. 

Format  line  16 

NNNN 

HA 

•Contains  only 

Table  D-1  Example  of  Task 

Information  Block  (TIB) 

"NNNN". 

(Page  H  of  H) 
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TIB  #D001,  Weapons/Equipment  Summary,  provides  formats  for  storage  of 
information  concerning  weapons  of  all  types.  Technical  characteristics, 
such  as  dimensions,  weights,  velocity,  and  range,  are  stored  and  may  be 
used  for  retrievals. 

TIB  #D002,  Personalities,  stores  names,  aliases,  and  detailed  descriptions 
of  persons  of  interest.  This  TIB  also  includes  information  concerning  the 
source  and  reliability  of  each  descriptive  item. 

TIB  #E001,  Country  Summary  Information,  contains  information  concerning 
individual  countries.  Estimates  of  the  stability  and  the  status  of  the 
current  government  are  among  the  items  included.  International 
affiliations  and  allegiances,  and  the  general  level  of  hostility,  are 
indicated.  Data  described  by  this  TIB  would  be  used  in  route  determination 
or  in  evacuation  planning,  where  the  degree  of  hostility  of  each  area  will 
have  an  effect  on  the  plan. 

TIB  #E002,  Installation  Information,  includes  descriptions  of  various 
types  of  installations.  In  addition  to  locations,  the  files  described  by 
this  TIB  will  Include  activity  in  the  following  categories: 
aircraft/vehicle,  construction,  weapons,  shipping/transportation, 
industrial,  road,  rail,  and  other  categories.  Defenses,  runways,  hangars, 
dispersals,  weapon  storage,  fuel  storage,  electronics,  access,  security, 
and  unusual  features  are  also  referenced.  Primary  and  secondary 
unit3/structures  are  described.  Dimensions  of  the  installation,  general 
and  specialized  facilities,  antennas,  and  power  sources  are  also  included 
for  some  installations. 

TIB  0FOO1,  Indicator  Lists,  contains  information  concerning  current 
indicator  status.  The  country  to  which  the  indicator  pertains,  together 
with  a  classification  of  the  indicator,  is  also  included  for  use  in 
retrieval. 
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TIB  #6001 ,  Collection  Request,  represents  the  standard  joint  Tactical  Air 
Reconnaissance/Surveillance  Request  Form  used  by  the  analyst.  In  addition, 
information  used  by  the  Collection  Coordinator  is  also  included. 

TIB  #H001 ,  Friendly  Mission  Information,  specifies  information  concerning 
type  of  mission,  date  and  time,  location,  destination,  expected  arrival 
date  and  time,  and  details  concerning  the  mission  units  and  aircraft. 

TIB  #1001 ,  Air  Route  Description,  provides  a  general  description  of  the 
route,  Including  the  type  of  mission  generally  using  the  route,  and 
indicates  weather  conditions  and  threats  on  the  route.  Route  restrictions 
are  also  described. 

TIB  #1002,  Air  Route  Segment  Description,  provides  more  detailed 
information  concerning  individual  route  segments.  Descriptions  and 
locations  of  Individual  segments,  details  of  threats,  facilities  located 
on  the  route  segment,  and  features  and  obstacles  are  listed.  Navigation 
aids  are  presented  in  detail.  An  assessment  of  the  suitability  of  the 
segment  for  various  mission  types  is  included. 

TIB  #J001,  Weather  Summary,  describes  current  weather  conditions  in 
selected  localities.  Information  concerning  general  weather  conditions  is 
Included,  and  provision  is  made  for  severe  weather  warnings. 
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The  GPM  was  designed  to  operate  on  DEC  PDP-11/70  equipment  under  the  IAS 
Operating  System.  The  system  configuration  is  shown  in  Figure  E-1 . 


The  User  Interface  consists  of  a  set  of  indirect  command  files,  which  the 
user  must  execute  in  order  to  provide  input.  These  inputs  are  used  to 
produce  data  buffers  for  use  by  the  monitor.  A  series  of  indirect  command 
files  can  be  used  to  specify  different  monitoring  options,  as  shown  in 
Figure  E-2: 

o  MCCNMS  -  task  names 

o  MCCXRV  -  send/receive  directives 

o  MCCQIO  -  QIOs 

o  MCCFLS  -  filenames  for  monitoring  I/O 

o  MCCTEX  -  task  execution  directives 


o  MCCTIN  -  mlscellar»c  .  us  directives 

o  MCCSEW  -  exit,  stop,  and  suspend  directives 

The  user  specifies  the  monitoring  options  for  a  monitoring  session  by 
executing  the  appropriate  indirect  command  files.  A  monitoring  session  is 
then  initialized  and  monitoring  Itself  begins.  At  the  end  of  the  session, 
a  separate  reporting  task  (MCCOUT)  accesses  the  disk  resident  monitored 
statistics  to  provide  formatted  reports  on  disk  statistics,  node  use,  task 
statistics,  directive  use,  and  I/O  to  file  names. 
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Figure  E-l  Monitor  Configuration 
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The  processing  tine,  amount  of  core  memory  use,  and  number  of  files  output 
by  the  GPM  are  a  function  of  the  number  of  options  seleoted  by  the  user. 
Any  combination  of  options  may  be  selected.  The  GPM  creates  a  set  of 
statistical  files  for  each  monitoring  session  that  is  conducted.  Each 
individual  file  generated  contains  the  results  of  monitoring  only  certain 
activities:  a  group  of  EMTs,  certain  task  names,  particular  disk  drives, 
etc.  Subsequent  monitoring  sessions  vill  generate  a  different  set  of 
files,  thus  allowing  the  user  to  save  historical  statistics  as  long  as 
they  are  required. 

During  the  Remote  Terminal  Emulation  (RTE)  tests,  the  GPM  was  used  to 
obtain  statistics  required  for  evaluation  of  the  three  systems  under  test. 
The  results  of  these  tests  are  included  in  Section  12.0  of  this  report. 


Appendix  P.  POBTHBB  RESEARCH 

F.1  Artlflolal  Intelligence  Experiments 

This  aeetion  describes  potential  further  use  of  the  test  facility 
developed  during  this  effort.  The  illustrations  provided  here  are  intended 
to  show  the  Banner  in  which  the  scenarios,  data  bases,  and  other 
oonponents  may  be  applied  to  the  evaluation  and  demonstration  of  other 
systeas  and  approaches.  Techniques  to  be  defined  and  described  here  are 
termed  "Artificial  Intelligence”  (AI)  in  the  sense  that  they  replicate, 
emulate,  or  augment  human  cognitive  processes. 

The  following  examples  Illustrate  AI  techniques  and  potential  I&W 
applications: 

o  Pattern  recognition  methods  may  be  used  to  identify  recurring 
patterns  of  events,  for  the  purpose  of  identifying  significant  events  or 
predicting  future  events.  Correlations  among  messages  oould  be  used  to 
form  clusters  of  messages  referencing  the  same  or  related  events. 

o  Automatic  update  facilities  could  be  provided,  in  which  incoming 
free- text  messages  are  analyzed  to  provide  formatted  information  for 
update  of  data  bases. 

o  Techniques  for  language  translation  may  be  used  to  provide 
natural  language  query  facilities  for  a  data  base  system. 

o  Methods  developed  in  an  experimental  context  for  question¬ 
answering  programs  could  be  adapted  to  extend  the  capabilities  of  a  data 
base  system. 


i 
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o  Programs  for  logical  inference  may  be  employed  to  show  the 
implications  of  current  events. 

o  Decision  analysis  systems  could  be  used  to  assist  the 
intelligence  officer  in  supplying  evidence  for  a  warning  or  other 
projection. 

o  A  knowledge-based  system,  containing  information  or  procedures 
derived  from  the  practice  of  experienced  intelligence  analysts,  could  be 
developed. 

The  tasks  described  here  are  intended  to  determine  whether  AI  techniques 
can  support  I&W  Intelligence  analysis,  using  data  bases,  scenarios,  and 
other  software  implemented  for  this  effort. 

Several  types  of  AI  have  already  been  studied  intensively  for  application 
to  the  I&W  environment.  They  include: 

o  The  Advanced  Indications  Technology  Experiment  (AITE)  and  its 
successor,  the  Prototype  Advanced  Indications  System. 

o  Waveform  recognition  techniques  applied  to  identification  of 
radar  and  other  electronic  emissions. 

o  Liiage  recognition  methods  used  for  analysis  of  aerial 
photographs. 

o  Automatic  translation  of  foreign  language  information, 
o  Analysis  of  messages  for  automatic  dissemination. 
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The  techniques  and  experiments  represented  by  these  developments  are 
significant  applications  of  AI  techniques  to  l&W  information  requirements, 
illustrating  the  practical  importance  of  AI  research.  The  purpose  of  the 
experiments  outlined  here  is  to  evaluate  additional  AI  applications,  using 
the  I4V  DBKl  evaluation  facility. 

The  field  of  AI  is  not  veil  defined,  but  may  be  generally  characterized  as 
the  application  of  techniques  based  on  human  information  processing, 
rather  than  traditional  mathematical,  statistical,  or  computational 
approaches. 

For  example,  in  its  early  versions,  AIS  relied  heavily  on  curve  fitting 
and  other  traditional  mathematical  approaches  to  obtain  prediotors  of 
significant  events.  The  number  of  events,  such  as  long-range  aircraft 
flights,  was  tallied,  and  significant  variations  from  the  norms  vere 
noted.  These  provided  indicators  of  potentially  signfioant  changes.  This 
early  approach  in  AIS  was  a  non-AI,  traditional  mathematical  solution. 

Later  versions  of  AIS  more  closely  resemble  AI,  since  they  use  reasoning 
processes  more  like  those  of  human  experts.  Human  reasoning  typloally 
takes  the  form  of  a  conditional,  if-then  statement:  If  the  Soviets  launch 
a  satellite  from  Base  X  on  a  Sunday,  rather  than  its  normal  weekday 
launch,  then  they  have  a  special  interest  in  the  area  under  surveillance 
by  the  satellite.  Like  a  knowledge-based  AI  system,  recent  experimental 
versions  of  AIS  contain  a  large  number  of  rules  of  this  type.  Typical 
rule-oriented  systems  resemble  human  experts  in  relying  on  somewhat 
informal  heuristics,  or  rules  of  thumb,  rather  than  on  formal  mathematical 
methods  of  data  analysis  and  reduction. 

For  the  purpose  of  the  tests  described  here,  we  will  use  a  portion  of  the 
EWAMS/WEIS  data  base  (see  Section  6.0).  Another  data  base  for 
consideration  would  be  the  Libyan  scenario  material,  using  Foreign 
Broadcast  Information  Service  (FBIS)  sources  (see  Section  7*0). 


Pattern  recognition  techniques  are  available  in  two  general  forms: 
statistical  and  syntactic.  Statistical  methods  include  the  use  of  the 
Fisher  discriminant,  Bayesian  classifiers  (and  more  tractable  substitutes 
for  them),  factor  analysis  and  other  statistical  clustering  techniques, 
various  regression  methods,  and  other  statistical  approaches.  Graphic 
methods  are  sometimes  combined  with  statistical  methods,  to  permit  the 
experimenter  to  visualize  the  structure  of  the  data,  and  to  draw  lines 
between  clusters  of  data  items  that  appear  to  be  distinct. 

Syntactic  methods  are  somewhat  newer  and  more  closely  related  to  other  AI 
approaches.  Essentially,  they  use  production  rules,  resembling  syntactic 
rules  in  linguistic  analysis  or  automata  theory,  to  describe  the 
requirements  for  inclusion  in  a  pattern  class.  A  syntactic  pattern 
recognition  system  thus  is  similar  to  a  rule-based  AI  system.  [Cf.  Paul  R. 
Cohen  and  Edward  A.  Felgenbaum,  Handbook  of  Artificial  Intelligence.  Los 
Altos:  William  Kaufmann,  1982,  Vol.  Ill,  pp.  287-291.] 

Pattern  recognition  and  correlation  techniques  may  be  used  to  recognize 
and  classify  events.  An  event  is  a  change  in  the  values  associated  with  an 
attribute  of  an  entity.  A  significant  event  is  one  that  requires  a 
response,  suoh  as  further  study,  or  issuance  of  a  warning  or  other 
message.  Event  analysis  includes: 

o  Determination  of  the  classification  to  which  an  event  belongs. 

o  Clustering  of  messages  which  refer  to  the  same  or  similar 
events. 

o  Identification  of  common  patterns  or  family  resemblances  among 
related  events. 

o  Prediction  of  future  events. 


The  goal  of  event  analysis  le  the  development  of  a  coherent  ploture  or 
model  of  the  event.  The  model  might  take  the  form  of  a  aet  of  statements 
relating  the  various  components  of  the  event  into  a  whole.  To  make  sense 
of  the  event ,  the  model  would  inolude  an  assessment  of  enemy  Intentions 
and  capabilities  as  related  to  further  events.  The  model  thus  serves  as 
the  basis  for  predictions  and  for  warnings. 

The  following  components  of  -event  analysis  were  listed  in  the  Benchmark 
Test  Plan: 

o  Event  correlation:  locating  other  data  records  which  reference 
similar  events,  or  other  aspects  of  the  same  event. 

o  Event  verification:  locating  other  records  which  will  tend  to 
increase  or  decrease  the  estimated  reliability  of  the  report. 

o  Event  expansion:  locating  other  records  which  contain  additional 
data  concerning  causes  or  effects  of  the  event. 

o  Event  coordination:  locating  other  records  of  related  or  similar 
events. 

The  Benchmark  Test  Plan  for  this  project  stated  that  it  was  possible  to 
perform  these  operations,  forming  a  composite  or  coordinated  event  record 
in  the  analyst  file,  which  contains  references  back  to  the  supporting 
data.  It  should  be  possible  for  the  analyst  to  prepare  a  data  record  for 
the  hypothesized  event  and  report  concerning  the  event,  using  report 
generation  facilities.  It  should  also  be  possible  to  display  the 
information  against  a  cartographic  background. 

The  first  method  for  grouping  messages  will  be  to  use  human  visual 
capabilities  to  Identify  clusters  of  geographically  related  items. 
Development  of  demonstration  facilities  for  the  I&W  DBMS  Analysis  has  made 


It  possible  to  display  looatlons  of  elements  of  the  WEIS  data  base  against 
a  cartographic  background.  A  map  of  the  selected  area  is  generated  at  the 
oolor  graphics  terminal,  and  message  locations  are  displayed  as  colored 
dots  on  the  map.  Using  a  cursor,  the  user  can  point  to  a  dot  on  the  map, 
whioh  will  cause  the  corresponding  message  to  be  displayed  on  another 
terminal. 

The  next  step  will  be  to  permit  the  user  to  draw  a  boundary  around  a  set 
of  messages,  and  to  retrieve  all  messages  lying  within  this  area.  As  the 
message  locations  are  displayed,  the  user  will  be  able  to  Identify 
clusters  of  messages  that  represent  a  single  event,  or  a  group  of  closely 
related  events. 

Since  the  demonstration  software  permits  an  area  search,  this  facility 
would  not  require  any  extensive  further  software,  but  it  would  require 
some  method  for  determining  whether  a  message  was  or  was  not  within  the 
boundary  that  the  user  has  drawn.  The  simplest  approach  would  be  to 
require  the  user  to  draw  the  boundaries  along  coordinate  lines  and  use 
existing  software  to  locate  messages  within  this  area. 

A  second  method  for  grouping  messages  is  to  Identify  time  clusters,  i.e. 
sequences  of  messages  within  a  limited  time  period.  Since  time  alone  is 
not  enough  to  identify  messages  with  related  subject  matter,  this  method 
may  be  used  in  conjunction  with  geographic  clustering.  The  following 
experiment  would  show  the  usefulness  of  this  approach: 


The  user  first  identifies  a  geographic  area  of  interest,  and  requests  the 
system  to  store  all  messages  from  within  this  area.  Next,  the  messages  are 
sorted  by  time  of  occurrence  (if  they  are  not  already  in  time  sequence). 
The  system  then  displays  the  locations  of  the  messages  in  sequence,  from 
earliest  to  latest.  This  time-sequence  display  should  give  a  clear  picture 
of  the  development  and  geographical  structure  of  an  event,  permitting  the 
analyst  to  extrapolate  to  future  developments.  The  geographical  pattern  of 
the  event  can  be  identified. 


Another  approach  would  identify  patterns  within  the  event  descriptions 
themselves,  and  could  serve  as  the  basis  for  locating  related  or  similar 
messages.  The  techniques  described  here  have  been  used  extensively  for 
content  analysis  of  free-text  data  bases  at  Cornell  and  Syracuse 
Universities. 

The  goal  of  content  analysis  is  to  identify  clusters  of  related  messages 
(or  other  texts)  within  the  data  base,  which  may  be  presumed  to  deal  with 
the  same  or  closely  related  topics.  In  general,  an  ideal  cluster  is  a  set 
of  items  which  are  more  highly  correlated  to  other  items  in  the  cluster 
than  to  any  items  outside  the  cluster.  Since  real  clusters  are  seldom 
ideal,  clustering  techniques  use  various  compromises  to  obtain  useful 
groups  of  items.  Each  member  of  a  group  or  cluster  of  correlated  messages 
is  an  example  of  the  pattern  that  identifies  members  of  the  cluster.  This 
pattern  can  be  used  as  the  key  to  recognizing  other  potential  members  of 
the  group. 

The  following  steps  are  usually  performed  in  developing  a  content  analysis 
system  of  this  type? 

o  Review  data  base  to  remove  non-content  words  (and,  or,  is,  but, 
etc.)  and  to  remove  syntactic  word  endings  (-ed,  -ing,  -s,  -ment,  -er, 
etc.),  leaving  word-stems. 

o  Identify  and  discard  word-stems  which  will  not  be  useful  for 
clustering,  such  as  words  which  occur  only  once  (and  thus  do  not  correlate 
with  anything)  and  words  which  occur  in  nearly  all  the  messages  (and  thus 
would  correlate  with  everything). 

o  For  the  k  words  remaining  after  this  culling  process,  form  a  k  x 
k  correlation  matrix,  where  the  more  highly  correlated  words  are  those 
that  occur  in  the  same  messages  with  the  same  frequency. 


o  For  the  n  messages,  form  an  n  x  n  correlation  matrix,  where  the 
more  highly  correlated  messages  are  those  which  contain  the  same  words,  or 


highly  correlated  words. 

o  Form  clusters  of  highly  correlated  messages,  representing  the 
patterns  that  occur  in  the  data  base. 

The  process  of  cluster  formation  is  a  non-trivial  task,  for  which  packaged 
clustering  routines  are  available.  The  message  patterns  represented  by  the 
clusters  can  now  be  used  for  automatic  identification  of  other  messages 
dealing  with  the  same  event  6r  subject  area.  A  fully  developed  pattern 
recognition  system  might  be  used  for  the  identification  of  significant 
events  in  the  stream  of  incoming  I&W  messages. 

A  pattern  recognition  system  of  this  type  could  be  used  to  perform  the 
four  operations  for  event  analysis  described  above:  correlation, 
verification,  expansion,  and  coordination.  A  substantial  software  effort 
is  required  to  provide  the  needed  correlation  routines,  but  the  existence 
of  the  I&W  DBMS  analysis  software  can  provide  much  of  the  required  support 
for  this  system. 

In  addition,  it  will  be  possible  to  obtain  summary  statistics  from  the 
WEIS/EWAMS  data  base,  particularly  from  the  free- text  portions,  which 
could  be  used  to  estimate  the  usefulness  of  this  approach.  Specifically,  a 
table  of  words  contained  in  the  free-text  portions  of  the  WEIS  data  base 
should  be  prepared  and  reviewed  to  determine,  on  an  intuitive  basis, 
whether  statistical  correlation  techniques  might  be  valuable  for 
developing  a  system  that  would  recognize  patterns  in  the  data.  This  review 
should  be  complete  enough  to  justify  a  recommendation  concerning  further 
work  in  this  area. 

A  completely  different  approach  to  pattern  recognition  in  the  WEIS  data 
base  would  use  syntactic  pattern  recognition  methods.  This  approach,  which 
is  similar  to  that  of  knowledge- based  AI  systems,  is  discussed  in  more 
detail  in  the  last  section  of  this  report. 


F.1.2 


Autonatlo  data  base  update  is  regularly  performed  at  ADCOM  In  processing 
formatted  data,  such  as  data  concerning  position  and  course  of  space 
objects.  This  information  is  extracted  and  inserted  automatically  in  the 
Space  and  Missile  OB  files.  The  goal  of  this  study  is  to  determine  whether 
automatic  data  base  update  is  feasible  when  the  source  of  information  is 
unformatted  or  partially  formatted  data.  For  example,  information 
concerning  the  location  of  Soviet  submarines  might  be  used  to  update  the 
appropriate  OB,  without  analyst  intervention. 

In  fully  developed  form,  such  a  facility  would  review  incoming  messages, 
such  as  GENSER  traffic,  identify  the  message  subject  on  the  basis  of  key 
words  appearing  in  the  text  (GENSER  messages  do  not  always  include  a 
separate  subject  line),  send  the  message  to  a  specialized  routine  for  data 
extraction,  and,  finally,  issue  a  call  to  the  DBMS  to  perform  the  actual 
updating  procedure.  Because  of  the  critical  importance  of  the  data 
contained  in  Intelligence  files,  redundancy  and  internal  validity  checks 
must  be  provided  within  the  system  to  keep  the  error  level  within 
tolerable  limits  and  to  reduce  the  possibility  of  catastrophic  error, 
which  might  include: 

o  Failure  to  identify  update  message. 

o  Misidentif ication  of  update  message,  with  update  performed  on 
wrong  files. 

|  o  Insertion  of  data  into  wrong  fields,  or  data  in  wrong  format. 

o  Cascading  errors,  i.e.  errors  in  data  items  affecting  other  data 
items,  or  growing  in  magnitude  with  each  update. 

I 

j  o  Accidental  destruction  of  existing  data. 

1 

i 

* 
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This  list  is  not  meant  to  be  exhaustive,  but  simply  to  illustrate  some  of 
the  opportunities  for  error  in  an  automatic  update  system.  Similar  errors 
can  occur  in  manual  update  systems,  but  there  is  no  information  to  show 
that  automatic  updates  are  more  or  less  error-prone  than  manual  updates. 

Within  the  context  of  the  I&W  DBMS  Analysis  facility,  it  is  possible  to 
demonstrate  and  test  automatic  update  procedures,  using  existing  data 
bases  and  the  DBMSs  under  test.  The  general  goal  of  this  demonstration 
would  be  to  determine  the  applicability  of  each  DBMS  to  such  procedures. 
GENSER  traffic  should  be  used  if  available;  however,  since  there  may  be 
some  delay  in  obtaining  GENSER  material,  this  discussion  will  assume  that 
the  WEIS/EWAMS  data  base  will  be  used.  This  will  simplify  the  problem,  but 
it  should  also  provide  a  demonstration  that  the  approach  is  a  reasonable 
one;  conversely,  if  the  problem  of  automatic  update  cannot  be  performed 
with  the  relatively  simple  WEIS  data  base  as  its  source,  it  is  likely  to 
even  more  difficult  to  use  GENSER  or  other  major  military  data  sources. 

The  first  step  in  this  demonstration  is  the  use  of  routines  to  extract 
information  from  the  formatted  section  of  the  WEIS  data.  Tables  should  be 
prepared  showing  the  number  of  interactions  between  countries,  the  number 
of  hostile  vs.  non-hostile  interactions,  and  the  number  of  interactions  of 
each  type. 

Next,  it  should  be  possible  to  update  tables  automatically.  A  new  WEIS 
message  is  read,  and  the  formatted  sections  are  translated  into  a  call  to 
the  appropriate  record  in  the  data  base.  The  existing  value  is  read,  the 
new  data  item  is  added  to  it,  and  the  updated  value  is  returned  to  the 
data  base.  For  example,  if  a  hostile  interaction  between  Israel  and  Syria 
is  input,  the  program  will  obtain  the  existing  number  of  hostile 
interactions  between  these  countries,  add  one  to  it,  and  return  the  new 


The  next  step  would  be  to  review  techniques  for  extracting  data  from  free 
text  materials.  Here,  the  verbal  sections  of  the  WEIS  data  base  could  be 
used.  They  are  considerably  shorter  than  the  GENSER  messages  and  more 
stereotyped  In  format,  but  for  that  reason  automatic  translation  would  be 
more  likely  to  succeed.  The  procedures  would  follow  the  same  pattern  as 
those  suggested  for  the  formatted  portions  of  the  WEIS  data. 

In  this  test,  the  problem  would  be  to  determine  whether  there  Is 
sufficient  consistency  in  the  form  of  the  free- text  summaries  to  permit 
automatic  identification  of  hostile  or  cooperative  interactions,  and  to 
identify  the  participating  countries.  Given  the  tables  of  hostile  and 
non-hostile  interactions  described  above,  this  function  will  attempt  to 
provide  automatic  updates  from  the  free- text  portions  of  the  WEIS  data 
base. 

Development  of  the  automatic  update  mechanism  for  use  with  WEIS  data  must 
next  be  extrapolated  into  the  substantive  problem  of  providing  an  update 
mechanism  with  GENSER  data.  The  question  to  be  asked  is  whether  this 
approach  is  likely  to  be  effective  when  a  realistic  intelligence  data 
source  is  used.  GENSER  messages  should  be  reviewed  to  determine: 

o  Which  messages  are  likely  to  be  used  as  inputs  to  an  automatic 

update  facility? 

o  Of  these  messages,  what  fields  or  key  words  are  present  that 
could  be  used  to  identify  and  classify  them? 

o  Will  it  be  possible  to  design  an  algorithm  for  extraction  of 
required  data  from  the  messages? 

o  Can  the  extracted  data  be  used  in  a  call  to  one  of  the  DBMSs  to 
update  the  appropriate  data  base? 

o  What  opportunities  for  error  are  there  in  this  process,  and  how 
can  the  destructive  effects  of  errors  be  prevented? 


In  the  original  proposal  for  this  project  (Section  3.6.2)  DHIL  was 
described  as  potentially  "the  standard  I&W  data  base  access  language.” 
Subsequent  clarification  from  RADC  indicated  that  full  development  of  a 
standard  language  was  beyond  the  scope  of  the  project,  and  DHIL  was 
tailored  specifically  to  the  job  of  I&W  scenario  development.  Later,  the 
orginal  project  plan  was  modified,  with  the  approval  of  RADC,  to  eliminate 
the  projected  use  of  automatic  translators  from  the  DHIL  into  individual 
data  base  access  languages.  The  translations  were  performed  manually.  The 
task  of  translating  DHIL  statements  into  forms  required  by  each  of  the 
DBMSs  has  provided  a  substantial  fund  of  information  concerning  the 
requirements  of  a  generalized  data  access  language,  and  this  Information 
should  be  preserved  as  background  for  a  design  document  outlining  the 
requirements  and  possible  formats  of  the  language. 

Should  the  DHIL  be  used  as  a  prototype  for  a  general  purpose  access 
language,  as  suggested  in  the  project  proposal?  Should  a  natural  language, 
such  as  English,  be  used  as  a  lingua  franca,  a  general  language  to  access 
all  data  bases?  Or  should  some  alternative  be  chosen?  Is  it  even  possible 
to  develop  a  generalized  data  access  language?  What  can  AI  research 
contribute? 

A  substantial  amount  of  AI  experience  has  gone  into  developing  systems  for 
understanding  natural  language,  and  for  answering  questions  posed  in 
natural  language.  There  is  no  substantial  evidence,  however,  that  natural 
language  is  the  most  effective  medium  of  communication  between  humans  and 
machines.  The  following  are  typical  arguments  against  the  use  of  natural 
language  as  a  query  language: 

o  Since  reliable  voice  input  is  still  not  available,  natural 
language  must  be  entered  through  a  typewriter  keyboard,  which  most  humans 
find  difficult  to  use  efficiently. 


o  Natural  language  Is  verbose,  which  means  that  a  great  deal  of 
typing  oust  be  done,  when  a  limited  number  of  brief  commands  would  be 
sufficient  for  most  DBMS  purposes. 

o  Queries  which  make  good  sense  in  vernacular  English  may  be 
misinterpreted  by  automatic  parsing  algorithms. 

o  All  existing  natural  language  processors  place  severe 
restrictions  on  the  vocabulary  and  syntax  of  the  commands  that  they  will 
recognize.  These  restrictions  may  be  extremely  frustrating  to  human  users. 

o  Syntax  and  spelling  errors  may  lead  to  misinterpretation  or 
rejection  of  the  command.  Retyping  an  extensive  command  is  burdensome  for 
the  user. 

These  objections  are  well  known  to  proponents  of  natural  language 
processing,  and  many  recent  systems  take  them  into  account.  Nevertheless, 
it  appears  that  natural  language  is  a  form  of  overkill  for  the  design  of 
an  I&W  DBMS  front  end: 

o  Since  the  DBMS  performs  a  very  limited  set  of  functions,  it  is 
not  neoessary  to  provide  the  software  required  for  processing  a  large 
subset  of  natural  language. 

o  No  query  language  permits  the  user  to  begin  writing  commands 
without  any  prior  training.  Since  the  user  must  be  trained,  it  is  possible 
that  a  simple  artificial  language  will  require  less  training  time  and 
effort,  and  will  be  more  reliable  in  actual  use,  than  a  restricted  subset 
of  natural  language. 

o  A  simple  query  language  could  use  mnemonics  that  are  more  easily 
remembered  than  natural  language  commands,  given  that  the  user  is 
permitted  to  write  only  a  limited  portion  of  the  full  natural  language. 
That  is,  the  user  could  easily  forget  some  of  the  restrictions  on  the 
natural  language  processor  that  he  or  she  is  using. 


These  objections  suggest  that  for  trained  users,  working  with  a  Halted 
set  of  objectives,  the  disadvantages  of  natural  language  may  outweigh  Its 
iuaediate  appeal.  A  specialized  query  language,  In  which  the  user  needs  to 
remember  only  a  small  number  of  commands,  and  which  has  a  simple, 
straightforward  syntax,  may  be  more  easily  learned,  may  be  more  easily 
used,  and  will  certainly  be  more  easily  Implemented,  than  a  natural 
language  processor.  DHIL  could  be  considered  as  a  prototype  for  such  a 
language. 

These  doubts  concerning  natural  language,  however,  should  not  be  taken  to 
be  a  rejection  of  all  work  that  AI  has  completed  in  the  development  of 
question  answering  systems.  On  the  contrary,  some  of  the  most  important 
and  interesting  work  that  AI  has  done  has  been  the  analysis  of  user 
questions  and  the  presuppositions  that  users  bring  to  a  system.  [Belnap, 
Nuel  D. ,  Jr.,  and  Steel,  Thomas  B.  Jr.,  The  Logic  of  Questions  and 
Answers,  New  Haven:Yale,  1976;  Lehnert,  Wendy  G. ,  The  Process  of  Question 
Answering,  Hillsdale,  N.J. :  Lawrence  Erlbaum  Associates,  1978.]  We  should 
attempt  to  see  how  this  AI  research  can  contribute  to  the  design  of  a 
user-oriented  query  language. 

We  have  two  possible  goals  for  research  in  this  area: 

o  Development  of  DHIL  on  the  basis  of  experience  in  translation 
into  DBMS  languages.  Development  could  mean  scuttling  DHIL  as  it  currently 
exists  and  designing  a  new  user  language. 

o  Application  of  AI  research  in  the  logic  of  questions  and 
answers,  specifically  in  the  problem  of  supplying  information  that  better 
meets  the  user's  needs. 

In  support  of  the  first  goe  *  hould  be  certain  that  we  maintain 
adequate  records  of  the  t&  lating  DHIL  statements  into  the 
formats  required  by  each  o f  JBMSs.  Records  should  indicate 
difficulties  in  translation,  useful  additional  commands,  problems  in 
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syntax,  ambiguities,  and  other  information.  The  goal  is  to  provide  a  fund 
of  experience  that  can  be  used  in  designing  a  general  purpose  language  for 
automatic  translation. 

In  addition  to  its  work  in  natural  language  processing,  AI  can  contribute 
to  the  analysis  of  queries  to  provide  more  adequate  responses.  The 
following  items  are  typical  -of  the  problems  that  AI  considers: 

o  It  should  not  be  necessary  to  repeat  a  query  in  full,  when  it  is 
closely  similar  to  the  preceding  query.  The  analyst  asks:  "What  is  the 
displacement  of  the  Krupny  class  destroyers?,"  and  receives  an  answer  from 
the  system.  Instead  of  repeating  the  full  query,  the  analyst  should  be 
able  to  type  simply:  "Kanin?”  with  the  system  filling  in  the  remaining 
information  from  memory. 

o  When  the  system  falls  to  produce  a  hit,  it  should  automatically 
broaden  the  area  of  the  search  until  a  hit  is  found.  When  performing  a 
circle  search,  retrieving  all  items  within  a  specified  geographic  area, 
the  system  should  be  able  to  expand  the  area  when  no  hits  are  found,  or 
when  the  analyst  is  not  satisfied  with  the  results. 

o  When  searching  for  names,  near-misses  should  be  available, 
because  of  variations  in  spelling  conventions.  This  facility  is 
particularly  important  in  searching  for  names  which  have  been  transcribed 
from  interrogations  and  other  verbal  sources,  where  the  transcribed 
spelling  may  vary  from  the  standard. 

These  examples  are  well  within  the  state  of  the  art  and,  in  fact,  are 
implemented  in  some  experimental  data  base  systems.  Within  the  scope  of 
the  I&W  DBMS  Analysis  facility,  the  question  will  simply  be  whether 


advanced  systems  of  this  type  will  be  available  to  users  of  the  DBMSs 
under  test.  Questions  like  the  following  should  be  asked: 

o  Does  the  user  have  to  specify  all  information  in  explicit  form, 
or  does  the  system  make  assumptions  concerning  the  user's  Implicit 
information  requirements? 

o  Does  the  system  attempt  to  oorrect  the  user's  spelling? 

o  If  a  syntax  or  spelling  error  is  detected,  does  the  user  have  to 
retype  the  entire  query  or  command? 

o  Is  there  any  sense  in  which  the  system  learns  from  the  user? 
For  example,  if  the  user  always  accesses  the  same  file,  will  the  system 
learn  to  open  that  file  automatically?  If  the  user  frequently  enters  the 
same  command,  can  that  command  be  saved  and  reentered,  or  does  the  user 
have  to  retype  it  every  time  it  is  used? 

o  Does  the  DBMS  permit  abbreviated  command  syntax  or  spelling? 
Facilities  like  these  have  become  so  familiar  that  it  seems  exaggerated  to 
call  them  "artificial  intelligence."  Nevertheless,  they  have  grown  out  of 
AI  research  and  are  typical  of  practical  applications  of  AI. 

An  AI  system  attempts  to  "understand”  the  user's  query,  which  means  that 
it  identifies  the  presuppositions  and  implications  of  the  query,  going 
beyond  what  the  user  has  specified  explicitly.  If  the  user  asks,  "How  many 
Soviet  fishing  vessels  are  in  the  Bering  Straits?,"  the  system  should  be 
able  not  only  to  perform  the  required  geographic  search,  but  also  to  give 
more  than  a  simple  answer,  "none,"  or  "16"  or  "23."  It  should  be  able  to 
say,  "None,  but  there  are  18  within  50  miles  of  the  Straits,"  or  "None, 
but  there  are  3  submarines  in  the  Straits,"  or  "None,  because  the  Straits 
are  frozen  over."  The  system  "understands"  that  the  user  is  interested  in 
identifying  threats  in  the  Bering  Straits  area,  and  it  provides  the  user 
with  enough  information  to  meet  this  implicit  goal. 
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Theorem  proving  techniques  have  been  sufficiently  developed  to  permit  the 
design  of  practical  systems  which  depend  on  logical  Inference.  Methods 
developed  over  the  past  twenty  years  extend  far  beyond  the  use  of  simple 
theorems  to  prove  formulas  in  a  logical  caloulus.  For  example: 

o  An  approach  to  automatic  oomputer  programming  uses  theorem 
proving  techniques  to  generate  programs  by  "proving"  assertions  about  the 
programs.  The  resulting  proof  is  the  required  computer  program. 

o  Instructions  for  the  control  of  robots  are  generated  by 
"proving”  the  result  of  their  actions.  The  proof  is  a  list  of  actions 
required  to  obtain  the  result. 

In  short,  automatic  theorem  proving  has  practical  applications,  in 
addition  to  its  theoretical  applications  in  formal  logic.  (In  fact,  the 
practical  applications  may  have  greater  long-term  significance  than  the 
work  in  abstract  logic,  where  one  well-known  result  —  that  there  is  no 
effective  decision  procedure  for  first-order  predicate  logics  —  places  an 
absolute  theoretical  limit  on  any  theorem  proving  algorithm.) 

Within  the  context  of  the  I&W  DBMS  test  facility,  this  research  should 
focus  on  the  question  of  meeting  I&W  analyst  requirements  in  conjunction 
with  the  DBMSs  under  test: 

o  To  what  extent  can  theorem  proving  techniques  improve  the 
quality  of  the  information  that  the  I&W  analyst  can  extract  from  an  I&W 
data  base? 

Although  modern  theorem  proving  techniques  have  grown  very  complex,  they 
tend  to  use  an  approach  that  we  all  learned  in  elementary  logic  classes: 
the  use  of  truth  tables.  All  possible  combinations  of  truth  values  are 
generated  to  determine  the  conditions  under  which  an  assertion  is  true  or 
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false.  If  a  set  of  assertions  oannot  all  be  true  simultaneously  (that  is, 
if  they  "clash"),  then  one  of  them  must  be  false.  The  goal  of  automatic 
theorem  proving  is  to  develop  efficient  methods  for  testing  large  numbers 


of  complex  assertions  for  clashes. 


One  application  to  IAW  would  be  to  test  the  assertions  contained  in  a  data 
base  to  locate  anomalies  or  inconsistencies.  This  would  require  a 
consistent  coding  of  WEIS  data  in  a  format  that  could  be  translated  into 
the  logical  notation  used  in  theorem  proving  systems.  In  an  experimental 
system,  the  data  could  be  reviewed  to  identify  errors,  anomalies,  and 
changes  over  time. 


Another  potential  application  would  use  theorem  proving  techniques  for 
locating  significant  events,  such  as  threats.  The  threat  would  be  entered 
as  the  conclusion  of  a  logical  deduction,  and  the  system  would  be  required 
to  prove  that  the  threat  exists.  The  proof  sequence  would  provide  the 
evidence  required  in  the  analyst's  report.  Development  of  this  approach 
could  make  a  significant  contribution  to  I&W  DBMS  analysis  and  evaluation. 


Some  related  approaches  are  discussed  in  Section  15.6  of  this  report. 


F.1.5 


Decision  analysis  is  based  on  a  well-defined  set  of  statistical  methods 
for  selecting  among  options,  using  assessments  of  the  probabilities  of 
contributing  events,  conditional  probabilities  (the  probability  of  A, 
given  that  B  occurs),  and  the  expected  gain  or  loss  for  each  outcome.  The 
approach  is  usually  tied  to  Bayes*  theorem,  a  formula  for  the  relations 
among  the  probabilities. 
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Decision  analysis  systems  have  been  widely  advocated  for  use  in  major 
business,  industrial,  and  military  applications,  although  there  have  been 
difficulties  in  securing  accurate  assessments  of  the  large  number  of 
probabilities  required  for  practical  use.  Much  of  the  current  work  in  this 
area  concentrates  on  the  user  interface,  attempting  to  make  it  easier  to 
secure  probability  assessments  from  persons  who  are  knowledgeable  in  the 
subject  matter  but  who  are  not  expert  statisticians. 

Military  Intelligence  analysis  requires  more  effective  methods  for  dealing 
with  uncertainty  in  the  Information  which  it  processes.  Messages  arriving 
at  an  intelligence  center  may  be  based  on  defector  reports,  prisoner 
interrogations,  intercepted  communications,  and  many  other  sources  of 
information  which  may  be  Intentionally  deceptive.  Electronic  sensing 
devices,  infrared  sensors,  and  photographic  equipment  have  finite  limits 
of  resolution,  and  the  objects  or  events  that  they  detect  may  be 
misldentified.  Even  when  all  available  information  is  accurate,  a 
potential  enemy  may  change  strategy  or  tactics  at  any  time,  in  directions 
which  are  unpredictable  even  in  principle.  In  short,  intelligence 
information  is  always  uncertain  to  some  degree. 

Although  there  has  been  some  research  in  the  measurement  and  reduction  of 
uncertainty,  there  is  no  effective  standardized  method  of  measuring 
uncertainty  or  of  combining  uncertain  information  from  heterogeneous 
sources.  Decision  analysis  has  been  proposed  as  an  effective  technique  for 
dealing  with  uncertainty,  but  it  has  not  been  widely  used  for  this 
purpose.  Instead: 

o  Intelligence  is  often  reported  with  vaguely  defined  phrases  like 
"it  is  believed  that"  or  "it  is  somewhat  probable  that,"  which  do  not 
provide  decision  makers  with  enough  information  to  support  any  clear 
conclusion. 


o  In  some  instances,  two  five-point  scales  representing  accuracy 
and  reliability  are  used;  but  research  has  shown  that  these  scales  are 
difficult  to  interpret  reliably. 
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o  Alternatively,  numerical  assessments  are  Included,  like  "there 
is  an  80  percent  probability  that"  or  "it  is  60  percent  likely  that," 
where  the  numbers  often  represent  intuitive  estimates,  rather  than 
fully-supported  assessments. 

The  use  of  sophisticated  mathematical  or  statistical  techniques  can  hardly 
be  justified  for  information  of.  this  quality. 

The  contribution  of  decision  analysis  is  in  providing  back-end  processing 
for  assessments  of  uncertainty.  The  Bayesian  model  is  an  effective  method 
for  combining  probabilities  from  various  sources  to  obtain  overall 
probability  assessments.  In  some  instances  (MYCIN  is  an  example)  rough 
numerical  measures  may  be  used,  rather  than  well-defined  probability 
assessments,  because  of  difficulties  in  using  Bayesian  statistics  with 
large  data  bases. 

The  major  focus  of  current  research,  however,  is  on  the  front  end,  the 
user  Interface.  The  user  may  fill  in  blanks  to  create  the  probabilities 
and  the  tree  structures  required  for  full  analysis.  The  user  may  return  to 
earlier  portions  of  the  tree  to  correct  faulty  probability  assessments, 
until  a  point  is  reached  at  which  the  decision  structure  is  fully 
analyzed. 

An  area  for  research  supported  by  the  I&W  DBMS  analysis  facility  would  be 
methods  for  attaching  probability  assessments  to  existing  data.  When 
information  is  retrieved  under  the  DBMS,  is  there  any  effective  way  in 
which  the  user  can  determine  the  reliability  or  accuracy  of  the  data?  Does 
the  DBMS  have  any  way  of  dealing  with  uncertain  or  unreliable  data? 
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The  question  Is  important,  because  the  DBMSs  typically  accept  data  as 
aoourate.  In  sost  applications,  such  as  commercial  or  financial  data 
processing  systems,  there  is  no  provision  for  probabilistic  information.  A 
bank,  for  example,  would  never  want  to  say,  "There  is  an  80  percent 
probability  that  Jones  still  owes  $1200  on  his  automobile  loan."  While 
there  will  inevitably  be  errors  in  data  collection  or  entry,  they  do  not 
include  the  type  of  uncertain  information  that  is  always  present  in 
intelligence  data  bases.  For  this  reason,  commercial  DBMSs  do  not  normally 
provide  a  capability  for  dealing  with  uncertainty. 

Conceptually,  it  would  not  be  difficult  to  include  a  field  which  would 
indicate  the  probability  or  the  degree  of  uncertainty  in  I4W  data.  Since 
this  information  is  rarely  accurate  to  more  than  one  digit  at  best  (an 
exception  would  be  sensor  reports,  where  the  accuracy  of  the  sensor  has 
been  accurately  determined),  one  byte  would  be  more  than  sufficient  to 
hold  the  probability  assessment. 

The  more  important  question  is  the  development  of  methods  for  making 
better  use  of  uncertainty  assessments.  Often,  they  seem  to  function 
largely  as  hedges,  to  protect  the  analyst  in  case  of  error.  If  the  analyst 
has  said,  "It  is  somewhat  likely  that  Israel  will  attack  Lebanon  within 
the  next  week,"  then  he  or  she  cannot  be  accused  of  error,  no  matter  what 
happens. 

In  the  field  of  weather  prediction,  scoring  rules  are  available  to  measure 
the  accuracy  of  forecasts.  When  a  weather  forecaster  announces,  "There  is 
a  40  percent  chance  of  rain  tomorrow,"  the  scoring  rule  provides  a 
statistically  valid  way  of  measuring  the  degree  to  which  the  forecast  was 
right  or  wrong.  The  theoretical  basis  for  these  scoring  rules  has  been 
extensively  developed  and  is  widely  used  for  rating  weather  predictions. 


There  is  no  equally  well  developed  theory  for  intelligence  estimates,  for 
a  number  of  reasons: 

o  Intelligence  analyses  rarely  have  the  kind  of  all-or-nothing 
confirmations  that  are  found  in  forecasts  of  rain  or  snow.  For  this 
reason,  it  may  be  difficult  to  tell  whether  an  intelligence  analysis  is 
confirmed  or  unconfirmed. 

o  Where  weather  forecasts  are  repeated  hundreds  or  thousands  of 
times,  and  thus  can  develop  an  adequate  statistical  basis  for  evaluation, 
intelligence  estimates  tend  to  be  one-of-a-kind. 

o  While  weather  predictions  have  no  effect  whatever  on  the  actual 
weather,  the  predictions  of  intelligence  analysts  can  (and  should)  lead  to 
actions  which  will  affect  the  outcome.  If  an  analyst  predicts  an  enemy 
attack,  the  action  of  preparing  for  the  attack  may  lead  the  enemy  to 
change  its  plans,  falsifying  the  prediction.  This  negative  feedback  effect 
may  make  it  difficult  to  determine  whether  an  intelligence  analysis  is 
right  or  wrong. 

o  In  any  case,  little  systematic  work  has  been  done  in  reviewing 
Intelligence  methods  to  determine  which  methods  are  most  effective.  There 
have,  of  course,  been  major  studies  of  Intelligence  analysis  in  limited 
critical  situations,  such  as  the  Pearl  Harbor  attack,  but  these  studies  do 
not  consider  the  routine,  day-to-day  work  of  the  I&W  analyst.  Without 
evaluation  of  past  work,  it  is  difficult  to  determine  which  types  of 
analysis  get  the  best  results. 
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An  extensive  study  of  I&W  analyses,  with  recommendations  for  the  treatment 
of  uncertainty,  would  be  required  for  a  full  analysis  of  this  problem.  A 
less  ambitious  goal  would  be  simply  to  determine  whether  there  is  some 
method,  within  the  capabilities  of  current  DBMSs,  to  indicate  the 
uncertainty  or  probability  of  error  in  the  data  base. 

It  should  be  emphasized  that  this  problem  is  not  the  same  as  the  problem 
of  maintaining  data  base  integrity,  which  is  essentially  a  problem  for  the 
DBMS  (preventing  accidental  destruction  of  data,  ensuring  that  all  data 
remain  accessible,  avoiding  inconsistencies  in  redundantly  stored  data, 
etc.)  The  problem  we  are  considering  here  is  that  of  uncertainty  within 
the  data  items  themselves,  ra'ther  them  possible  errors  in  data  management. 
The  goal  of  the  suggested  experiments  would  be  to  determine  whether 
uncertainty  can  be  represented  effectively  within  the  data  base. 

F.1.6  Knowledge-Based  Systems 

Here,  as  in  other  paragraphs  in  this  section,  it  is  essential  to 
concentrate  on  systems  and  methods  which  can  actually  be  used  by  analysts 
working  in  the  field,  rather  than  on  purely  speculative  systems  of  the 
distant  future.  Very  recent  results  (since  1980)  have  indicated  that  AI 
has  come  out  of  the  laboratory  and  into  the  real  world.  AI*s  practical 
importance  has  been  signaled  by  the  extensive  commitment  of  corporations 
like  Schlumberger  and  Texas  Instruments  to  AI  approaches  in  geological 
analysis  for  petroleum  exploration,  among  many  other  examples. 

A  Knowledge- Based  System  (KBS)  is  essentially  a  compiler  where  the 
knowledge  takes  the  form  of  rules  or  procedures,  or  a  data  base  system 
where  the  knowledge  is  introduced  as  a  list  of  facts.  The  KBS  itself 
simply  provides  the  software  for  effective  access  to  knowledge.  Knowledge 
is  typically  gathered  from  experts,  who  describe  the  heuristics  or  rules 
of  thumb  that  they  use  for  arriving  at  conclusions.  Such  a  system  is 
sometimes  called  an  "expert  system." 


Some  KBSs  have  been  developed  for  specialized  problem  areas,  such  as 
medical  diagnosis  (MYC1N)  and  speech  understanding  (HEARSAY).  These  two 
systems  have  been  generalized  to  permit  them  to  be  used  with  other  types 
of  knowledge.  Other  systems  have  been  built  from  the  start  as  the 
framework  for  general  purpose  KBSs.  The  Knowledge  Representation  Language 
(KRL)  is  an  example  of  an  approach  to  rapid  development  of  a  KBS,  using 
expert  knowledge  as  its  base. 

The  line  between  KBSs  and  DBMSs  is  not  sharply  drawn;  in  fact,  many  of  the 
DBMSs  have  capabilities  which  are  comparable  to  those  of  KBS3.  One 
direction  for  research  would  be  to  determine  which  of  the  well-known  KBSs 
—  MYCIN,  HEARSAY,  etc.  —  would  be  most  useful  in  X&W  analysis.  Such  a 
study  would  show  the  way  in  which  advanced  systems  might  be  adapted  to  the 
operational  environment. 

Another  approach  would  be  to  ask  what  facilities,  comparable  to  advanced 
AI  facilities,  now  exist  in  operational  DBMSs,  which  are  capable  of 
handling  the  large  data  bases  and  rapid  computation  required  by  I&W 
analysts. 

What  capabilities  might  be  included  in  a  DBMS  which  would  give  it  the 
flexibility  and  power  of  an  AI  system?  Here  are  some  examples  (including 
several  suggestions  made  earlier  in  this  section): 

o  Access  to  multiple  data  bases  in  varying  formats.  A  relatively 
small  I&W  center  ha3  more  than  30  data  bases  available.  At  another  center, 
a  recent  inventory  included  more  than  100  data  bases,  some  of  which  are 
very  large.  Each  of  these  collections  of  data  ic  stored  in  a  different 
format,  and  is  accessed  in  a  different  way.  It  should  be  possible  to 
simplify  access  to  data  bases  in  different  structures  and  formats. 


o 


It  should  be  possible  for  an  analyst,  using  a  single,  very 
general  query,  to  obtain  Information  from  any  one  of  these  data  bases, 
with  the  system  selecting  the  proper  source.  Moreover,  it  should  be 
possible  for  one  data  base  system  to  query  another  system  when  information 
is  required,  and  combine  the  data  extracted  from  more  than  one  system  to 
formulate  an  appropriate  response  to  a  single  query. 

o  At  no  point  should  the  user  be  forced  to  learn  a  new  access 
language,  or  to  devise  a  complex  search  strategy  for  obtaining  information 
when  it  is  needed. 

o  An  essential  task  of  I&W  intelligence  analysis  is  the  detection 
and  identification  of  anomalous  events.  From  the  time  of  Alexander  the 
Great,  military  strategy  has  emphasized  the  need  for  surprise  —  this  is, 
for  performing  precisely  those  actions  for  which  the  adversary  is 
unprepared.  A  self-organizing  system  will  be  one  which  rapidly  reorganizes 
its  structure  to  take  account  of  anomalous  events  and  to  reduce  the 
likelihood  of  surprise.  In  addition  to  responding  to  time- tested 
indicators  of  potentially  significant  events,  it  will  locate  areas  of 
emerging  interest  ~  meetings  of  high-level  Soviet  scientists,  for 
example,  or  an  increase  in  satellite  surveillance  —  even  when  these 
developments  have  not  been  pre-programmed  by  the  analyst  as  potential 
indicators. 

o  Existing  DBMSs  are  often  difficult  to  use.  Briefly-trained 
personnel  on  relatively  short  assignments  cannot  be  expected  to  become 
computer  experts.  The  use  of  many  systems,  however,  requires  that  the 
analyst  become  virtually  a  computer  programmer  in  order  to  obtain  required 
information.  An  intelligent  DBMS  should  make  it  possible  for  the  analyst 
to  enter  a  query  in  a  simple,  easily-learned  language.  When  the  analyst 
has  become  familiar  with  one  set  of  techniques,  it  should  not  be  necessary 
to  learn  a  new  accessing  language  with  each  new  data  base,  but  to  continue 
to  use  the  language  and  techniques  which  have  already  been  learned. 


o  The  system  should  anticipate  the  user's  needs.  Rather  than  a 
simple  "yes"  or  "no"  in  response  to  a  query,  it  should  be  able  to  provide 
the  reasoning  behind  its  response;  it  should  be  able  to  justify  its 
answer. 

o  It  should,  moreover,  be  able  to  provide  near-oisses;  if  the  user 
asks,  "Are  there  Chinese  tanks  in  Vietnam?,”  it  should  be  able  to  reply, 
•No,  but  they're  five  miles  from  the  border.”  Such  facilities  are  now 
available  only  on  AI  systems  with  very  small  data  bases.  It  should  be 
possible  to  make  them  available  for  very  large,  complex  data  bases,  like 
those  encountered  in  intelligence  applications. 

o  The  intelligence  community  today  is  becoming  increasingly  aware 
of  the  need  for  quality  control.  Intelligence  production  is  a  difficult 
job,  and  the  development  of  more  effective  techniques  requires  an 
assessment  of  the  results  of  past  intelligence  products.  Although  the 
popular  press  has  publicized  some  of  the  successes  and  failures  of  the 
intelligence  community,  what  is  required  is  a  careful,  day-by-day 
assessment  of  intelligence  production,  in  order  to  provide  the  feedback 
required  for  improving  intelligence  methods.  An  intelligent  DBMS  will  be 
self-assessing.  It  will  provide  techniques  for  reviewing  past  performance, 
comparing  earlier  predictions  and  estimates  with  the  actual  outcomes,  and 
locating  the  areas  in  which  failures  have  occurred.  It  will  assist  in 
locating  the  techniques  or  indicators  which  have  been  successful.  It  will 
learn  from  past  experience.  Such  systems  have  long  been  a  goal  of  AI 
research;  similar  techniques  should  now  be  applied  to  the  assessment  and 
improvement  of  operational  systems  for  the  I4W  analyst. 
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o  Statistical  methods  for  trend  analysis,  curve  fitting,  and  other 
analytic  techniques  for  the  support  of  I&W  have  been  developed.  While  many 
of  these  systems  are  extremely  sophisticated,  they  have  also  proved  to  be 
difficult  to  use,  particularly  when  the  users  have  little  background  in 
the  statistical  methods  involved.  An  intelligent  DBMS  should  make  it 
possible  for  a  user  to  indicate  a  general  problem  or  area  of  conoern,  with 
the  system  itself  selecting  the  statistical  methods,  or  other  approaches, 
which  are  appropriate  for  the  data.  For  example,  the  chi-square  statistic 
should  be  used  to  determine  whether  the  differences  among  certain 
measurements  are  significant,  providing  that  the  sample  size  is  large 
enough,  and  that  other  constraints  upon  the  data  are  met.  For  other 
applications,  a  nonparametric  test  may  be  used.  But  the  I&W  analyst  should 
not  have  to  be  concerned  with  the  subtle  differences  among  the  various 
statistical  measures;  the  analyst  should  not  even  have  to  recognize  that  a 
statistical  measure  should  be  used.  The  system  itself  should  be  capable  of 
making  these  choices,  based  on  the  character! sties  of  the  data  and  the 
information  requirements  of  the  problem  at  hand. 

This  list  represents  a  selection  of  the  advanced  facilities  that  I&W 
analysts  could  be  given  in  a  system  which  incorporates  AI  techniques*  The 
I&W  DBMS  Analysis  facility  provides  an  environment  in  which  such  systems 
can  be  tested  and  demonstrated. 


F.2  Data  Base  Machine  Experiments 

This  section  includes  two  subsections  describing  possible  tests  and 
demonstrations  of  data  base  machines: 

o  The  first  set  of  experiments  outlines  Remote  Terminal  Emulation 
(RTE)  tests  for  a  Data  Base  Machine  (DBM). 


o 


The  second  set  uses  the  I&W  DBMS  facility  for  test  and 
evaluation  of  a  DBM  for  distributed  I&W  applications. 


The  purpose  of  this  section  is  to  provide  concrete  illustrations  of  the 
manner  in  which  the  I&W  DBMS  evaluation  facility  could  be  applied  to 
further  tests  in  support  of  I&W  intelligence  analysis. 


F.2.1  rte  Teata  of.  Data.  Baas.  MaaMjaa 

Data  base  machines  have  been  introduced  as  potential  replacements  for 
software  DBMSs.  The  purpose  of  this  set  of  tests  is  to  provide  direct 
comparisons  of  the  performance  of  an  existing  DBM  through  the  use  of 
benchmark  tests  developed  for  evaluating  DBMSs. 

Data  base  machines  appear  capable  of  offloading  the  data  base  management 
functions  from  a  general-purpose  CPU  to  a  specialized  processor,  with  a 
resulting  increase  in  processing  efficiency,  as  measured  by  such  factors 
as  response  time,  throughput,  costs,  and  storage  efficiency  (i.e.  disk 
space  required  for  a  given  volume  of  data,  disk  I/O  requirements  for  a 
sequence  of  accesses,  etc.)  These  advantages  may  or  may  not  be  apparent  in 
application  to  I&W  intelligence  data  processing. 

Experiments  would  include  testing  of  a  DBM,  such  as  the  Britton-Lee 
IDM-500,  using  the  I&W  DBMS  scenarios,  monitors,  and  data  bases.  The 
primary  software  development  would  be  the  adaptation  of  the  scenarios  and 
data  bases  for  operation  on  the  data  base  machine. 

The  I&W  DBMS  Analysis  has  provided  measures  of  performance  of  three  DBMSs 
against  a  set  of  scenarios.  The  outcome  of  this  analysis  is  a  set  of 
performance  parameters  of  the  DBMSs,  establishing  a  baseline  against  which 
performance  of  the  DBM  may  be  measured.  To  obtain  these  performance 
measures,  the  I&W  DBMS  Analysis  has  developed  scenarios,  data  bases, 
drivers,  and  other  software  which  can  support  testing  of  the  DBM.  This 
effort  would  use  the  results  of  the  tests  of  software  DBMSs,  together  with 
software  developed  for  those  tests,  to  determine  whether  the  DBM  provides 
a  significant  advantage  for  I&W  data  processing. 


The  first  task  would  be  the  design  of  Remote  Terminal  Emulation  (RTE) 
tests  of  the  data  base  machine,  developing  software  as  needed  to  oonvert 
existing  scenarios  and  data  bases  into  formats  required  for  inputs  to  the 
data  base  machine.  The  scenarios  should  be  Identical  in  structure  to  those 
previously  used  for  testing  software  DBMSs.  The  goal  of  this  task  is  to 
provide  data  which  are  comparable  in  form  to  the  data  obtained  from  the 
earlier  tests  of  software  DBMSs. 

RTE  tests  would  then  be  performed,  providing  performance  statistics  for 
the  DBM.  At  least  the  following  measures  of  performance  could  be  obtained: 
response  times,  retrieval  times,  CPU  times,  overall  (clock)  times,  number 
of  disk  accesses,  disk  head  movements,  and  number  of  I/O  requests 
processed. 


A  Live  Test  Demonstration  (LTD)  could  also  be  prepared  and  executed.  The 
purpose  of  this  test  would  be  to  obtain  qualitative  factors  which  were  not 
measured  during  the  RTE,  and  to  provide  the  basis  for  a  demonstration  of 
DBM  capabilities.  Such  factors  as  ease  of  use,  comprehensibility  of  the 
user  language,  time  required  for  data  preparation,  and  other  human  and 
qualitative  faotora  could  then  be  determined. 

A  weighting  of  evaluation  factors,  to  ensure  that  the  most  significant 
features  are  given  proper  emphasis,  would  be  prepared  and  applied  to  the 
results  of  the  tests.  These  factors  would  be  compared  to  identical  factors 
obtained  from  the  software  DBMSs. 

F.2.2  Distributed  Data  Base  Machine  Evaluation 

Recent  emphasis  on  distributed  data  bases  and  distributed  computer 
processing  in  the  I*W  environment  has  raised  questions  of  survivability  of 
such  systems.  Traditionally,  survivability  has  required  the  development  of 
redundant  facilities,  at  the  cost  of  more  than  doubling  hardware 
requirements.  Data  base  maohines  may  provide  the  basis  for  a  lower-cost 
approach  by  eliminating  the  need  for  duplicating  general  purpose 
computers,  through  the  use  of  specialized  backup  facilities  for  data  base 
systems. 


This  project  would  develop  designs  for  distributed  I&H  analysis  facilities 
using  offloading  oapabilities  of  data  base  machines  for 
cost-effectiveness.  Performance  tests  of  a  data  base  machine  will  be 
required  to  determine  design  parameters. 

The  projeot  would  include  testing  of  a  data  base  maohine,  as  well  as 
development  of  generalized  system  specifications  for  a  distributed  I&H 
data  system.  A  detailed  simulation  employing  data  bases  and  procedures 
similar  to  those  employed  in  the  I&H  environment  would  be  required  to 
determine  design  parameters. 

It  would  begin  with  a  study  of  survivability  requirements  for  distributed 
data  bases  in  the  I&H  environment.  At  least  the  following  problems  would 
be  characterized  and  quantified:  data  volatility,  data  base  size 
requirements,  site  locations,  minimum  transmission  rates,  security 
requirements,  cryptographic  transmissions,  data  integrity  and  consistency 
requirements.  A  detailed  specification  of  I&H  survivability  requirements, 
as  applied  to  distributed  data  base  systems,  would  be  the  first  product  of 
this  research. 

An  initial  survlvable  system  design  could  then  be  prepared,  indicating 
those  features  and  performance  parameters  that  would  be  required  to  ensure 
a  stated  probability  of  survival  of  a  I&H  distributed  data  base  under 
stated  conditions  of  threat.  The  purpose  of  this  initial  design  would  be 
to  identify  performance  requirements  for  hardware  support  for  a  survlvable 
system. 

A  test  plan  would  then  be  prepared.  The  I&H  DBMS  scenarios,  data  bases, 
monitors,  and  other  software  would  be  available  for  the  tests.  The  purpose 
of  the  tests  would  be  to  obtain  detailed,  verified  information  concerning 
hardware  performance  for  use  in  final  system  designs. 


Following  approval  of  the  teat  plan,  the  teata  would  be  carried  out  in 
aooordanoe  with  the  plan.  Teata  night  inolude  comparisons  of  performance 
of  the  DBM  against  performance  of  a  general  purpose  computer  system,  to 
determine  whether  there  were  gains  in  performance  and  Improved 
oost/performance  ratios  obtained  through  the  use  of  the  DBM.  Problems 
identified  during  the  initial  study  phase  would  be  specifically  addressed 
and  potential  solutions  would  be  proposed  and  documented. 

A  report,  including  verified  performance  data,  would  then  prepared 

indicating  the  applicability  of  a  DBM  to  I&W  distributed  data  bases,  with 
emphasis  on  provisions  for  survivability.  The  report  would  inolude  a 
recommendation  based  on  the  initial  requirements  study  and  on  performance 
testing,  concerning  the  contribution  of  specialized  data  base  maohines  to 
the  solution  of  the  I&W  survivability  problem. 


The  purpose  of  this  section  is  to  illustrate  the  type  of  research  that 
might  be  supported  by  the  I&W  DBMS  Analysis  facility  delivered  to  RADC  at 
the  conclusion  of  this  project.  This  section  will  outline  the  goals  and 
design  constraints  that  are  apparent  at  this  time  in  the  development  of  a 
general  Knowledge  Based  Processor  (KBP). 


The  KBP  is  intended  as  an  interface  between  the  user  and  a  DBMS.  This 
means  that  the  commercial  DBMS  can  be  employed  for  storage  and  retrieval 
of  data,  and  for  many  of  the  other  functions  that  would  ordinarily  require 
detailed  programming.  On  the  other  side  is  the  interface  with  the  user, 
who  enters  commands  and  queries.  More  importantly,  the  user  suggests  rules 
for  the  KBP  to  use  in  generating  calls  to  the  DBMS.  The  KBP  accepts, 
stores,  and  processes  these  rules. 
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In  this  Illustration,  the  user  interface  is  not  a  "natural  language" 
processor.  This  design  decision  is  intended  to  serve  two  purposes:  First, 
it  relieves  the  developers  of  the  task  of  designing  and  developing  a 
natural  language  system,  which  is  peripheral  to  the  goals  of  DBMS 
analysis,  extremely  large,  and  quite  risky  (i.e.,  it  might  not  work). 
Second,  there  is  no  convincing  evidence  that  natural  language  is  better, 
within  the  bounds  of  the  tasks  for  which  the  KBP  might  be  used,  than  a 
simple  set  of  codes.  The  user  can  learn  to  use  the  codes  just  as  quickly, 
and  with  as  great  a  facility,  as  he  or  she  can  learn  the  constraints  and 
conventions  of  any  "natural  language"  processor  that  can  reasonably  be 
provided.  For  these  two  reasons,  it  will  be  assumed  that  the  user  language 
is  a  fairly  simple  set  of  commands,  similar  to  SEQUEL. 


Another  design  assumption  is  that  a  relational  data  base  system  will  be 
used.  This  assumption  is  consistent  with  the  recommendation  of  ORACLE  in 
the  I&W  DBMS  Analysis. 

The  KBP  would  use  the  scenarios  developed  for  the  I&W  DBMS,  together  with 
the  data  bases  that  support  them.  In  the  end,  the  KBP  is  intended  to  be  a 
generalized  structure  that  would  permit  the  storage  and  processing  of 
rules  for  any  type  of  data  base,  for  any  reasonable  application;  but  the 
I&W  software  would  provide  a  wide  range  of  subjects  which  can  be  used  for 
test  and  demonstration.  It  seems  better  to  use  existing  material  when  the 
alternative  would  be  to  write  new  scenarios  and  data  bases  for 
demonstrations,  which  would  be  no  more  general  than  the  I&W  materials. 

The  following  design  components,  then,  would  be  used  to  support  the  KBP: 

o  Scenarios  from  the  I&W  DBMS  Analysis. 

o  Data  bases  from  I&W,  at  least  for  some  initial  tests.  The 

general  forms  (i.e.  the  TIBS)  would  be  more  valuable  than  the 
data  bases  themselves,  for  the  purpose  of  describing  what  the 
KBP  would  do. 

o  A  DBMS  operating  under  an  existing  system. 
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F.3.1 


The  format  of  the  command  language  Is  taken  to  be  SEQUEL-like.  When  the 
user  types  SEQUEL  commands  like: 

SELECT  S#, STATUS 
FROM  S 

WHERE  CITY='PARIS' 

The  KBP  recognizes  them  as  legitimate  SEQUEL  commands  and  simply  passes 
them  through  to  the  DBMS  without  processing.  Responses  from  the  DBMS  to 
the  user  are  also  passed  through,  without  processing.  In  other  words,  a 
user  could  use  the  DBMS  in  the  normal  way,  without  even  knowing  that  the 
KBP  functions  were  there. 

Error  handling  would  depend  on  the  command.  SEQUEL  errors  would  be  handled 
by  the  DBMS,  and  the  KBP  would  have  Its  own  set  of  error  handling 
procedures.  Obviously,  if  a  KBP  command  accidentally  gets  transmitted  to 
the  DBMS,  or  vice  versa,  it  may  be  hard  for  the  user  to  understand  what's 
gone  wrong. 

The  real  work  that  the  KBP  does  is  to  generate  queries  in  SEQUEL,  which  it 
submits  to  the  DBMS,  and  to  intercept  responses  from  the  DBMS  for  further 
processing. 


P.3.2 


The  suggested  language  for  implementation  is  C.  Typically,  artificial 
intelligence  systems  are  implemented  in  some  version  of  LISP,  or  in  a 
LISP-based  language  like  PLANNER.  However,  Implementing  the  KBP  in  C  would 
enhance  its  portability,  at  the  possible  expense  of  its  ability  to  use 
existing  AI  programs. 
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P.3.3  Rules 


What  the  EBP  would  do  would  be  to  process  rules.  Specifically,  the  user 
would  enter  a  number  of  rules,  representing  "knowledge,"  over  a  period  of 
time.  These  would  be  saved,  probably  by  making  use  of  the  DBMS  to  allocate 
and  store  them  like  any  other  data  file. 

The  rules  would  then  be  accessed  by  the  EBP,  which  would  retrieve  them 
from  the  data  base  into  a  temporary  file,  and  use  them  to  perform 
specified  operations.  Typically,  this  means  comparing  data  items  against 
each  of  the  rules,  determining  whether  they  match  the  elements  of  the 
left-hand  side  of  the  rule,  and  carrying  out  the  designated  operation  if 
there  is  a  match. 

For  example,  suppose  that  a  rule  states:  "If  there  are  troop  maneuvers 
when  the  commander  is  present  on  the  battlefield,  there  is  a  high 
likelihood  of  attack."  This  rule  generates  a  query  to  the  data  base, 
asking  for  the  location  of  the  commander  whenever  a  troop  maneuver  is 
reported.  If  the  commander's  looation  is  sufficiently  close  to  the 
maneuver,  a  potential  alarm  is  generated.  The  analyst  then  has  the 
opportunity  to  review  the  potential  alarm. 

One  problem  will  be  to  determine  when  to  attempt  the  search.  Clearly,  once 
the  EBP  has  generated  a  search  for  a  specific  item  in  the  antecedent  (the 
left-hand  side)  of  the  rule,  there  is  no  need  to  search  for  the  same  item 
again.  It  should  not  keep  searching  repeatedly  through  the  same  data.  The 
search  should  be  performed  only  when  it  is  needed. 

This  suggests  the  need  for  demons  that  watch  over  new  entries  to  the  data 
base.  A  demon  is  a  mask  or  matcher,  which  is  applied  to  the  stream  of  data 
entering  the  data  base.  When  a  data  record  is  matched,  a  procedure  is 
initiated,  which  performs  some  pre-specified  job.  Typically,  the  job  would 


be  to  oarry  out  an  additional  search  of  the  data  base,  to  oompare  the 
results  with  results  obtained  by  some  other  demon,  to  send  a  message  to 
the  terminal,  or  to  do  whatever  else  has  been  specified  by  the  rule. 


F.3.4  Data  Structures 

The  data  structure  suggested  for  this  implementation  is  not  the  usual 
network  structure  used  by  AI  systems.  Instead,  a  relational  data  base  is 
used.  This  should  mean  a  far  less  complex  structure,  and  probably  a  less 
fragile  one,  than  those  usually  used.  The  data  bases  that  l&W  analysts 
will  be  working  with  are  more  volatile  than  typical  AI  data  bases. 

Semantic  nets  are  frequently  used  as  a  means  of  representing  relationships 
and  dependencies  among  data  items  in  typical  knowledge  representation 
schemes.  If  a  relational  structure  is  to  be  used  there  should  probably  be 
some  way  of  showing  hierarchical  and  network  structures,  if  the  system  is 
to  be  built  on  traditional  AI  procedures. 

F.3>5  Demonstration 

For  an  effective  demonstration,  there  must  be  a  set  of  rules  for  the 
system  to  exercise.  Perhaps  100  rules  will  be  needed  for  an  initial 
demonstration.  They  might  be  obtained  by  tracing  through  the  scenarios  and 
Identifying  the  reasoning  processes  that  are  used  by  the  analysts  in  the 
scenarios.  A  place  to  start  would  be  the  Libyan  scenario  described  in 
Section  7.0 ,  which  contains  several  examples  of  the  analyst's  reasoning. 

The  KBP  described  in  this  section  illustrates  the  way  in  which  the  test 
facility  developed  for  the  I&W  DBMS  Analysis  may  be  used  to  support  test, 
analysis,  evaluation,  and  advanced  research  in  support  of  intelligence 
analysts. 
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